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ABSTRACT 

This  Command  Center  Library  Model  Document  (CCLMD)  was  developed  under  the  Compre¬ 
hensive  Approach  for  Reusable  Ddense  Software  (CARDS)  Prt^am  to  help  facilitate  advances 
in  software  reuse  methods.  It  rq}resents  the  current  state  of  the  CARDS  CImnmand  Center  Li- 
iMtury  Model.  It  is  a  "living"  document,  and  will  be  updated  with  every  library  release.  This 
document  desoibes  how  software  engineering  relates  and  feeds  back  to  Domain  Engineering, 
how  Dmnain  Engineering  compares  and  contrasts  to  Library  Modeling,  and  examines  modeling 
conc^ts  and  q)ecializatioa/aggregati<m  hierarchies. 

This  document  is  specific  to  relette  4.0  of  the  Cotnmand  Center  Lilx-ary  Model  in  its  description 
of  requirements,  architectures,  qualified  components,  system  composition,  and  future  direction. 
The  intended  audience  is  anyone  desiring  an  understanding  of  the  CARDS  Command  Center 
Library  Model  and  wantii^  a  view  of  the  curratt  Library  release.  A  knowledge  of  software 
engineering  coiioq>ts  is  assumed. 
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1  Introduction 

This  Command  Center  Library  (CCL)  Model  Document  describes  a  version  of  the  Comprehensive 
Approach  fa-  Reusable  Defense  Software  (CARDS)  CCL  Model.  This  release  replaces  earlier 
versions  of  this  document.  For  descriptive  purposes,  this  Model  is  referred  to  as  CCL  release 
4.0,  an  encoding  of  the  Generic  Command  Center  Architecture  (GCCA)  of  the  July  1992 
Portable,  Reusable,  Integrated  Software  Modules  (PRISM)  prototype,  into  the  RLF  (Reuse 
Ubiary  Framewo-k)  [CARDS93a].  RLF  is  a  part  of  the  CARDS  library  infrastructure  which 
can  be  thought  of  as  both  a  tool  and  a  fomalism. 

CARDS  library  models  are  being  iteratively  developed.  The  original  CARDS  model  is  being 
enhanced  to  reflect  changes  in  the  GCCA  and  to  provide  additional  detail.  The  command  center 
library  model  will  go  through  several  significant  revisions.  CCL  releases  will  include  updates 
to  this  document. 

The  purpose  of  this  document  is  to: 

•  Describe  this  CCL  Model  release. 

•  Describe  how  this  release  library  model  is  related  to  PRISM. 

•  Provide  the  reader  with  an  understanding  of  what  CARDS  library  models  represent 
and  how  they  are  related  to  domain  analysis. 

Section  2  provides  a  top-level  description  of  domain  engineering  and  library  models  which  may 
be  skipped  if  you  are  familiar  with  the  topics.  Section  2  also  provides  a  high-level  description 
of  the  semantics  of  the  RLF  meta-model,  i.e.,  the  knowledge-r^resentation  formalism  used  to 
encode  library  models.  This  description  is  useful  fer  understanding  parts  of  Section  3. 

Section  3  describes  this  release,  provides  a  high-level  description  of  the  aspects  of  the  PRISM 
architecture  encoded  in  the  release  library,  and  describes  in  detail  how  this  release  library  model 
is  related  to  the  PRISM  architecture.  Section  3  also  describes  current  plans  for  evolving  this 
release. 

Appendix  A  is  a  bibliography  of  sources  used  to  compile  this  document. 

Appendix  B  is  a  glossary  of  terms  used  within  this  document. 

^pendix  C  is  a  list  of  actions  contained  within  this  release. 

Terms  having  a  specific  technical  meaning  are  italicized  the  first  time  they  are  used  and  appear 
in  the  glossaiy.  Emphasized  words  appear  in  bold. 

1.1  Sources  of  Input 

An  important  requirement  fa-  any  project  attempting  to  perform  a  domain  analysis,  or  to 
represent  a  generic  architecture  for  a  class  of  software  systems,  is  that  several  different  system 
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implementations  be  examined.  For  CARDS,  so  far.  the  primary  input,  and  the  only  implemented 
system,  has  been  the  PRISM  generic  command  center.  Information  from  PRISM  has  included 
a  generic  architecture,  access  to  PRISM  source  code  which  the  CARDS  team  has  examined  to 
uncover  low  level  architectural  details,  and  interaction  with  PRISM  on  issues  of  mutual  invest. 

CARDS  has  also  used  the  Defense  Infcxmation  Systems  Agency  (DISA)  Command  Center 
Design  Handbook  (CCDH)  [DISA91]  for  very  high  level  infcxmation,  primarily  in  the  area  of 
functional  requirements,  and  also  the  Department  of  Defense  (DoD)  Technicjal  Reference  Mcxiel 
[DOD92]. 

U  Release  Notes  4.0 

The  following  are  additions  and  changes  to  the  CARDS  Command  Center  Library  for  Release 
4.0.  The  additions  follow  the  last  release  of  the  CARDS  Command  Center  Library  3.3,  on  25 
February  1994. 

Section  3.6,  previously  Qualified  Components,  now  discusses  the  Component  Classes.  The 
following  sections  are  now  organized: 

3.7  Qualified  Components 

3.8  Reference  Models 

3.9  System  Compcjsition 

3.10  Component  Qualification  Tool 

3.11  System  Demonstrations 

3.12  Interoperability 

3.13  Future  Directions/Enhancements 

Section  6.0,  Library  Actions,  has  been  modified.  The  definitions  are  provided  for  each  of  the 
actons,  but  the  list  of  nodes  at  which  these  actions  cxxur  has  been  removed. 
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2  Domain  Engineering  and  Library  Modeling 

Although  reuse  may  be  i^}proached  in  a  variety  of  informal  ways,  CARDS  position  is  that  a 
formal,  systematic  integration  of  reuse  into  the  conventicmal  software  develt^ment  process  yields 
substantially  greater  rewards.  The  basis  for  this  increased  formality  is  the  emerging  disciplines  of 
domain  analysis  and  domain  engineering.  Figure  2-1  illustrates  the  corresponding  relationships 
between  aspects  of  domain  engineering  and  software  engineering.  The  current  state  of  research 
and  practice  of  domain  analysis  and  domain  engineering  are  well  represented  in  an  TF.F.R  tutorial, 
Domain  Analysis  and  Software  Systems  Modeling  [PRIE92].  The  key  points  are  that; 

*  Domain  Engineering  targets  a  weU-defined  application  area  (or  domain)  and  results 
in  the  creation  of  various  products  characterizing  this  domain  (e.g.,  the  domain 
model). 

*  A  key  step  in  domain  engineering  is  domain  analysis,  which  is  roughly  analogous 
to  software  engineering  requirements  analysis,  except  that  domain  analysis  describes 
the  requirements  of  a  family  of  systems  (i.e.,  the  requirements  of  the  domain),  while 
software  engineering  requirements  analysis  focuses  on  the  needs  of  a  particular 
system  in  question. 

A  domain  model  may  encompass  not  only  the  results  of  the  domain  analysis  (as  just  defined), 
but  may  also  include  other  aspects  of  the  domain  as  well,  including  a  generic  architecture  for 
systems  within  the  domain,  and  reusable  components  that  satisfy  the  conditions  of  the  generic 
architecture. 


Figure  2-1  Software  and  Domain  Engineering  Process 

This  itemization  is  not  meant  as  a  precise  and  fixed  definition  of  domain  engineering  (since  this 
is  a  still-emerging  discipline),  but  rather  as  a  basis  for  understanding  the  relationship  of  CARDS 
libraries  to  both  domain  engineering  and  software  engineering  processes. 


Page  3 


STARS-VC-B01S/002/00 


31  May  1994 


Note  that  in  the  above  summary  the  terms  domain  analysis,  dmnain  model  and  get^c 
architecture  are  used,  but  the  terms  library  model  and  library  modeling  are  conspicuously  absent. 
The  reason  for  distinguishing  library  models  and  modeling  from  domain  models  and  modeling 
is  twofold. 

•  Since  CARDS  is  meant  to  provide  a  generic  capability  for  constructing 
dmnain-specific  reuse  libraries  [CARDS94d],  it  is  important  that  CARDS  does  not 
preemptively  select  one  set  of  domain  engineering  techniques  at  the  expense  of  oth- 
m.  Since  different  qsplicatimi  domains  (and  different  DoD  programs)  may  be  best 
served  by  different  domain  analysis  and  domain  modeling  techniques,  any  such 
CARDS  selection  would  be  premature  and  counterproductive. 

•  The  decision  of  which  domain  engineering  by-products  to  c^ture,  and  how  to  rep¬ 
resent  them,  is  a  design  decision  based  not  only  upon  the  nature  of  the  domain  and 
the  domain  engineering  analysis  techniques  used,  but  also  on  the  anticipated  use  of 
these  products  during  software  engineering.  That  is,  the  reuse  rqx>sitory  acts  as  an 
integrating  agent  between  domain  engineering  and  software  engineering  process. 
The  form  this  integrating  agent  (Le..  the  repository)  needs  to  take  is  dependent  upon 
both  endpoints  of  the  integration  relation  •  domain  engineering  and  software 
engine^ing.  This  point  is  elabOTated  in  the  following  section. 


2.1  Scoping  CARDS  Repositories 


It  is  possible,  as  in  Figure  2-2,  to  scope  the  repository  to  capture  only  the  reusable  components 
produced  as  a  result  of  the  implementation  phase  of  domain  engineering  processes.  In  Figure 
2-2,  this  scrying  is  denoted  as  a  parts  library.  The  utility  of  parts  libraries  without  including 
some  form  of  architectural  context  may  seem  limited,  but  can  be  justified  in  cases  where  the 
domain  architecture  is  unstable  (i.e.,  still  undergoing  technological  evolution  or  standardization), 
ca*  where  a  relatively  small  number  of  components  in  the  library  would  not  justify  the  investment 
in  maintaining  an  up-to-date  architectural  description.  Note  in  Figure  2-2  that  reusable  parts  can 
be  "used"  during  system  implementation,  but  that  an  "understanding"  of  what  parts  are  available 
in  a  repository  can  aid  in  system  specification. 

In  Figure  2-3,  the  scope  of  the  rqsository  has  been  extended  to  encompass  the  reusable 
components  as  well  as  an  architectural  model  capturing  the  relationships  among  the  components, 
and  describes  the  purpose  of  the  components  within  an  overall  system.  One  advantage  of 
sudi  a  library,  denoted  as  generic  architecture  library  in  Figure  2-3,  is  that  the  additional  contmct 
information  provided  for  reusable  components  can  support  the  automatic  compositiem  of  systems 
or  parts  of  systems.  For  example,  if  a  component  implementing  part  of  a  database  subsystem 
were  selected  for  use  in  an  implication,  the  generic  architecture  would  provide  the  basis  for  the 
automatic  selection  and  retrieval  of  any  components  that  were  implied  by  the  selection  of  the 
original  component  (e.g.,  SQL  interface  code  peculiar  to  a  particular  relational  database  vendor). 
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Figure  2-2  Implementation  Based  Reuse 

In  addition,  a  generic  architecture  library  can  make  the  browsing  and  searching  of  large  libraries 
simpler  and  more  meaningful  to  engineers  than,  for  example,  faceted  classification  schemes  re¬ 
quiring  strict  usage  of  library-specific  keywords.  Note  that  in  Figure  2-3  the  addition  of  generic 
architecture  information  in  the  library  model  extends  the  "use”  relation  to  include  both  system 
specification  and  implementation,  while  requirements  analysis  can  be  aided  by  "understanding" 
the  architecture  supporting  applications  within  a  domain. 

Figure  2-4,  extends  the  scope  of  the  repository  to  encompass  all  of  the  by-products  of  domain 
engineering.  This  additional  scoping  broadens  the  focus  of  the  reuse  library  to  incorporate 
domain  variance  as  well  as  domain  commonality.  While  generic  architectures  focus  on  what 
is  the  same  across  {q)plicatians  in  a  domain,  a  domain  model  also  captures  differences  across 
triplications  in  a  domain.  This  broadened  focus  can  support  the  capture  of  design  rationale  fa* 
alternative  designs  of  the  underlying  generic  architecture;  this,  in  turn,  would  be  instrumental 
for  evolving  the  domain  architecture  in  response  to  new  technology  and  new  demands  on  the 
previously  developed  triplications. 

In  Figure  2-4  the  advantages  of  a  domain  model  library  are  shown  both  by  illustrating  the  "use" 
relationships  present  throughout  software  engin^ring  processes,  and  by  illustrating  the  potential 
feedbadc  lo<r>  from  software  engineering  to  the  domain  model.  This  is  done  by  capturing  the 
variations  of  each  successive  system  developed  from  the  reuse  library  and  why  these  systems 
varied. 
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CARDS  views  a  library  as  a  library  model  and  a  set  of  {^)plications,  and  the  construction  of 
a  library  model  as  a  design  activity  balancing  various  requirements.  What  goes  into  and  what 
comes  out  of  a  library  is  dependent  upon  die  library  modeling  formalism  used,  the  kind  of 
domain  analysis  conducted,  and  the  kind  of  library  applications  needing  to  be  constructed  to 
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support  the  anticipated  system  engineering  processes.  The  library  model  includes  inf<xmation  in 
addititm  to  that  derived  from,  or  pertinent  to  domain  analysis  [CARDS94d]. 

Ttore  are  two  aptM-oadwa  to  implementing  a  reuse  lilMvy:  eompoment-boied  and  wiodel-baud. 

•  Component-based  libraries  are  organued  around  a  collectitH)  of  reusable  compo¬ 
nents.  The  undo-lying  operational  concq>t  is  that  of  search  and  retrieval  of 
individual  cmnptments.  Components  found  in  such  librari<»  are  classified  in  l»-oad, 
generaliaed  categories. 

•  Model-based  libraries  use  dtnnain  models  as  a  foundaticm  for  library  organization 
and  a  framework  for  suf^Kxling  ^>plications  exploiting  these  models  to  automate 
various  library  services.  Model-based  libraries  encmnpass  information  such  as  do¬ 
main  knowledge,  generic  architecture  specifications,  requirements,  and 
implementatitm  restrictions,  as  well  as  software  artifacts  [CARDS94d]. 

One  of  the  visible  efforts  of  library  analysis  is  diat  of  organizing  the  storage  and  retrieval  of  the 
reusable  C(»np<ments.  CARDS  q»proach  is  fumiamentally  model-based  (the  motivation  has  more 
to  do  with  the  retrieval  of  components,  and  with  the  capture  of  reusable  informatitm  that  is  lost 
in  comptHient-based  libraries,  than  with  storage).  The  idea  is  that  one  of  the  major  obstacles  to 
reuse  is  the  difficulty  potential  reusers  have  in  locating  reusable  products.  Models  are  a  very 
powerful  mechanism  for  organizing  components  and  facilitating  user  access  to  them 

A  CARDS  model  is  a  re]msentation  of  a  specific  type  of  af^lication  area  (often  referred  to  as 
a  domain)  which  is  simply  a  limited  subject  area.  Because  it  mirrors  the  organization  of  the 
part  of  the  real  world  using  the  components  being  stored,  it  provides  a  means  of  organizing  and 
accessing  a  store  mechanism.  Components  are  "attached"  to  the  model  in  the  spots  r^resenting 
their  use  in  real  world  ^^lications.  The  fact  that  it  mirrors  the  application  area  makes  it  a  natural 
way  for  the  user  to  locate  the  components  they  are  interested  in.  This  user  friendliness  is  one 
of  the  main  motivations  for  organizing  the  repository  stwage  and  retrieval  around  the  model. 

The  otiher  motivation  is  that  the  model  is  the  starting  point  for  potentially  many  powerful  tools 
to  aid  the  user  in  reuse  related  activities.  Because  the  model  is  "computafionally  accessible" 
and  is  a  detailed  picture  of  what  is  involved  in  the  domain,  it  is  an  excellent  starting  point  for 
building  tools  that  can  "reason”  about  the  various  elements  involved  in  the  domain,  including 
the  q)ecific  components  being  stored  in  the  library.  Inference  engines  are  used  to  analyze  the 
information  encoded  in  the  model  and  apply  various  types  of  understanding  to  produce  results 
sudi  as  software  configuration. 

The  initiai  scope  of  the  CARDS  CCL  includes  both  the  high  level  PRISM  architecture  and 
descriptions  of  the  components  used  to  implement  this  model  in  demonstration  prototypes.  Thus, 
this  lilnary  release  can  be  considered  a  generic  architecture  library  as  depicted  in  Figure  2-3. 
As  the  command  center  model  matures,  the  CARDS  library  evolves  from  a  generic  architecture 
type  to  a  domain  model  type,  permitting  more  powerful  tools  and  information  for  the  user.  This 
domain  model  library  will  incorpm'ate  mwe  information  potaining  to  domain  analysis  and  will 
receive  user  feedback  on  the  various  instantiations  of  the  systems  within  the  library. 
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Hkmi^  •  domtin  analytit  may  be  condittted  to  a  large  extent  without  regard  to  the  final  form  erf 
its  pixxhicts,  the  knowtedge  acquired  can  be  more  fully  realized  once  it  is  harnessed  by  a  library 
model  in  some  formalism.  RLF  is  the  medianism  used  to  implement  the  CARDS  CCL  since  it 
integrates  a  knowledge  rqxesentation  scheme,  rule-based  inferemung  and  a  graphical  browser. 
The  desolation  of  die  nature  of  the  model  requires  an  overview  of  the  encoding  mechanisms. 


2J  AdaKNET 

RLP  has  a  knowledge  r^mentadon  scheme,  called  AdaKNET,  which  facilitates  the  classificaticm 
(rf  lilxary  emnpements.  AdaKNET  can  be  thought  of  as  a  graph,  in  whidi  the  nodes  rq^resent 
general  categories  or  specific  objects,  and  the  edges  rqxesent  relationships  between  the  nod». 
Nodes.  re(»esenting  general  classes  of  knowledge,  are  called  concepts  or  categories.  There 
are  two  basic  types  of  relationships,  specialization  ("is-a")  and  aggregation  ("has-a"),  described 
below.  Two  kinds  of  hierarchies  are  built  with  the  concepts  and  relationships:  specialization 
and  aggregation  hiearchies. 

23.1  Specialization 


There  is  exaedy  one  specialization  hierarchy  in  any  given  "model".  The  specialization  hierarchy 
is  a  way  of  defining  the  concqits.  It  can  be  thought  of  as  a  glossary,  and  can  be  compared  to 
the  need  to  (teclare  variables  in  a  traditional  computer  programming  language.  The  top  level 
concqrt  is  usually  given  a  very  generic  name,  such  as  thing  or  entity,  and  all  other  concepts  are 
defined  to  be  specializations  of  it.  This  hierarchy  is  made  by  asserting  that  the  "is-a"  relatiimship 
holds  between  two  ctmeepts.  Tlus  relationship  is  unidirectional. 

The  assertion  is  that  less_general_concept  q>eciaiizes  more_general_concept.  Or, 
less_general_concept  is-a  more_general_concept. 

As  depicted  in  Figure  2-5,  animal  specializes  thing,  mammal  specializes  animal,  and  cow 
specializes  mammal.  The  modeler  can  build  a  set  of  concq>ts  rqpresenting  all  the  parts  of 
the  domain  which  need  to  be  referenced.  In  this  view,  concepts  are  represented  as  a  single  oval 
and  the  specialization  links  are  represented  as  double  lined  arrou^.  A  concept  rqjresente  abstract 
categoies  of  concise  things  and  may  also  be  called  a  generic  concqpt,  a  category  or  a  class. 

The  specialization  hierarchy  provides  the  vocabulary  for  an  AdaKNET  model.  Because  every 
concq>t  in  the  model  is  defined  in  this  hierarchy  as  being  a  specialization  of  some  other  concq>t, 
we  have  a  way  of  understanding  the  context  of  any  concept  we  encounter  in  the  model. 
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Figure  2-5  Specializetim  Hierarchy 

13J2  Individuation 

Within  the  ^>ecializatiaD  hierarchy,  the  top-level  node  is  very  generic  and  becomes  more 
and  more  specific  at  each  level  until  finally  the  leaf  nodes  nuy  contain  specific  examples  of 
their  parent  concq>ts.  A  leaf  node  rq>resenting  a  particular  comptment  or  elemental  piece  of 
informadtm  instantiated  from  its  parent  concept  is  known  as  an  individual  or  object.  It  also  may 
be  known  as  an  individual  ccmcept,  or  an  instance. 

Individuation  is  the  relationship  between  a  parent  ccmcept  and  the  instantiation  (individual)  of  that 
parent  concept.  Individuatimi  lies  within  the  specialization  hierarchy  and  defines  an  individuation 
link  between  a  concqit  and  an  individual. 

Referring  to  Figure  2-5,  take  note  of  the  individual  ctmcept  called  ^Bossie’.  In  this  example, 
*Bos8ie*  is  our  specific  cow.  Yet,  *Bossie*  is  but  one  of  an  infinite  number  of  possibilities  for  an 
instantiatian  of  the  conc^t  cow.  As  shown  in  this  Figure,  individuals  are  re^xesented  as  double 
ovals  and  the  individuation  link  is  repiesoited  as  a  three  lined  arrow. 

23 J  Aggregation 

Each  of  the  concepts  in  the  specialization  hierarchy  may  have  relationshi]:^  of  the  ”has-a”  nature 
with  any  other  concqpt  in  the  model,  including  itself.  These  relationships  may  express  attributes, 
characteristics,  features  (as  the  term  is  used  in  FODA  [KANG90]),  functional  capabilities, 
requirements  or  metrics,  any  relationship  that  exists  between  two  concq)ts  which  is  not  a 
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q)ecitlizattoa  reUtumship.  Since  any  coocept  may  have  aggregatim  hierarchy  lunter  it,  and 
it  is  iK>t  required  that  all  the  umts  of  aggregadtm  structure  tie  together,  the  model  usually 
cmstains  many  sqMuate  pieces  of  aggregation  hierarchy.  While  every  concqjt  must  i^^iear  in  the 
^)ecialization  hiowchy.  it  is  not  necessary  for  every  concq[>t  to  be  mvolved  in  an  aggregatimi 
relationsh^). 

The  aggregaticm  hierarchy  is  built  by  beginning  with  the  concq^t  representing  the  thing  being 
modeled,  such  as  commandjceiUer,  and  listing  all  of  its  has-a  relaticmships.  These  reladonshtps 
show  substructure,  characteristics  or  other  sorts  of  relationships  and  ve  often  called  roles.  Each 
of  these  relatitmships  has  a  name,  type  and  range.  The  type  is  the  ccmc^t  being  pointed  to.  The 
range  is  an  txdered  pair,  zero  to  infinity,  or  some  narrower  specification,  including  a  converged 
range  such  as  2  to  2.  This  value  represents  how  many  copies  of  that  relationship  may/must  exist 
simultaneously. 

Bach  ccHKq)t  automatically  inherits  the  aggregaticm  relationships  of  its  ancestors  in  the 
specialization  hierarchy.  AdaKNET  suf^xxts  multiple  inheritance,  so  a  ccmcept  having  mcxe 
than  one  parent  inherits  die  aggregation  relaticmsh^  of  each.  The  range.  aiKl  the  possible 
values  of  the  type,  may  be  narrowed  cm  subsequent  leveh  of  the  hierarchy  (by  the  concqits  that 
inherited  them)  to  suppcxt  the  logical  structure  of  the  aggregaticm  hierarchy.  This  is  called  role 
restriction. 

Referring  to  Figure  2-6,  notice  that  the  individual  ‘Bosae*  has  what  is  known  as  a  filler  that 
satisfies  its  predecesscxr’s  inherited  relaticmship  of  makes.milk  to  the  type  milk.  Individuals  must 
have  sucdi  aggregational  relationships  to  otho-  individuals.  In  this  case  the  individual  type  is 
*Boenie*s  milk*  which  is  an  individuaticm  of  the  cmncept  milk. 

23.4  The  Model 


These  two  types  of  hierarchy  are  completely  intertwined.  In  most  cases  what  the  modeler  and 
the  end  user  diink  of  as  "the  model"  is  actually  a  subtree  (really  a  subgraph,  but  it  is  generally 
thcmght  of  as  a  tree)  rooted  at  the  concept  representing  the  thing  to  be  modeled  and  all  the 
aggregaticm  hierarchy  under  it. 

A  fiiU  model  includes  much  more  than  the  structural  csrganization  expressed  in  AdaKNET,  with 
the  inferencers,  discussed  below,  being  the  most  important  other  part 

However,  in  this  document  the  focus  is  on  the  modeTs  structural  part  because  the  structure  is 
the  aspect  that  is  most  usefully  described.  Discussing  why  the  structure  was  organized  as  it  was 
communicates  scmiething  about  the  modeler’s  understanding  of  the  command  center  domain. 
In  ccmtrast  the  iaferencm  are  aids  for  accomplishing  tasks.  Their  actual  implementation  is 
irrelevant  to  the  mid  user. 
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Figure  2-6  Aggregation  Hierarchy 

2.4  Inferaidiig 

There  are  two  inference  engines  associated  with  AdaKNET.  AdaTAU  was  written  in  conjunction 
with  AdaKNET  and  is  a  part  of  the  RLF.  It  is  tightly  integrated  with  the  Graphical  Browser. 
CLIPS  (C  Language  Integrated  Production  System)[GIAR92]  is  used  in  inferencing  tools  that 
wwk  on  the  AdaKNET  structure.  CLIPS  was  devel(^>ed  for  the  National  Aeronautic  and  Space 
Administration  (NASA)  and  is  available  for  a  very  moderate  fee,  tx-  free  for  use  on  Air  Force 
or  NASA  projects.  These  two  inference  engines  (X’ovide  similar  basic  capabilities,  but  CLIPS 
is  more  computationally  powerful  and  also  has  the  capability  of  querying  the  AdaKNET  model 
structure. 

Both  inference  engines  permit  the  modeler  to  write  inferencers,  units  of  code  expressed  as  rules 
about  the  model.  These  units,  smnetimes  called  rule-bases,  are  associated  with  specific  concepts 
in  the  AdaKNET  model. 

2.5  Actions 

Any  executable  program  or  process,  called  an  "action",  may  be  associated  with  any  concept  by 
the  creatw  of  the  library.  The  mechanism  of  invoicing  an  "action"  at  a  concept  is  typically  used 
to  view  textual  information  associated  with  the  conc^t,  but  has  general  iq>plicability  to  a  wide 
variety  of  needs. 

Actions  can  be  thought  of  as  strings  which  are  executed  in  an  operating  system  when  the  action 
is  invoked.  Actitm  "targets"  are  the  strings  r^resenting  the  object  upon  which  the  action  acts. 
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For  example,  a  file  describing  the  database  management  system  INGRES  may  be  viewed  at  the 
c(»icq>t  ingres  by  including  an  actitm  which  execu^  the  command: 

preview  ingres_desc.txt 

In  this  example,  "ingres_desc.txt"  is  the  action  target.  The  same  action,  with  a  different  action 
target,  may  be  made  available  at  the  concept  Sybase  which  executes  the  command: 

preview  sybBse_desc.txt 

Actions  are  inherited  by  concepts  in  much  the  same  manner  as  roles.  All  subconcepts  are 
subsumed  by  a  conc^t  declaring  an  action  will  have  that  action  available.  Actions  can  also  be 
inherited  along  several  specialization  links  in  the  case  of  multiple  inheritance. 

Actions,  again  much  like  roles,  can  also  be  restricted  at  subconcepts  below  the  concept  where 
they  are  declared.  Action  targets  can  be  renamed  at  subconcepts,  regardless  of  inheritance. 


I 

I 
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3  Command  Center  Library  Model 

The  CARDS  command  center  model  is  the  basis  for  a  domain-specific  software  reuse  library  fw 
the  command  center  domain.  The  current  primary  source  of  information  about  command  centers 
is  the  PRISM  Program  at  ESC/ENS,  Hanscom  AFB.  PRISM  is  designing  a  generic  architecture 
and  developing  components  for  prototyping  Air  Force  command  centers.  This  chapter  describes 
how  the  PRISM  work  relates  to  the  current  CARDS  library  model. 

3.1  Scope  of  the  CARDS  Command  Center  Library  Release  4.0 

The  initial  scope  of  the  CARDS  CCL  included  both  the  high  level  PRISM  architecture  and 
descriptions  of  the  components  used  to  implement  the  model  in  demonstration  prototjrpes. 

This  scqjing  remained  the  primary  emphasis  by  CARDS  throughout  Phase  2,  although  some 
significant  extensions  of  the  CARDS  CCL  to  capture  useful  variant  information  (i.e.,  domain 
model  library  information)  have  been  produced  as  a  byproduct  of  the  system  compositirm  tool 
and  component  qualification  process  development. 

CARDS  libraries  are  produced  by  encoding  various  results  of  domain  engineering  processes 
into  the  RLF.  The  decision  about  what  kinds  of  domain  engineering  by-products  to  encode 
(i.e.,  determining  the  library  scope)  is  a  design  decision  which  must  consider  the  nature  of  the 
domain,  the  domain  engineering  processes,  and,  especially,  the  demand-side  software  engineering 
processes  which  will  make  use  of  CARDS  libraries. 

3.2  Background 

The  Generic  Command  Center  (GCC)  Project  (the  fcx'erunner  of  PRISM)  integrated  components 
fra*  use  in  command  centers.  [ESD90]  states: 

"The  Generic  Command  Center  Phase  2  prototype  is  an  implementation  of  a  portion  of  the 
Generic  Command  Center  (GCC)  architecture.  The  purpose  of  this  prototype  is  to  validate 
the  concept  of  building  command  centers  by  integrating  large  reusable  components. 

The  required  functionality  is  that  of  processing...  messages;  establishing  a  database; 
displaying  information  in  a  geographic  information  system;  creating  tables  of  information; 
and  creating  briefings  that  interface  with  the  database.  The  implementation  was  consistent 
with  the  GCC  architecture  and  used  several  commercial  off-the-shelf  (COTS)  products  as 
components...  The  results  of  the  GCC  Phase  2  are  extremely  promising  toward  the  concept 
feasibility  of  integrating  large  software  components  for  application  in  the  Command 
Center  domain." 

PRISM  has  a  more  ambitious  goal  of  developing  a  real  generic  architecture  for  command  centers. 
It  proposes  to  provide  a  user  with  80%  of  the  required  resources  to  produce  a  new  command 
center  as  well  as  information  on  acquiring  or  producing  the  remainder.  The  CARDS  library 
model  is  incrementally  encoding  information  generated  by  PRISM. 
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3J  CARDS  Command  Center  Model  History 


The  initial  library  model  was  encoded  in  RLF  while  the  GCC  Phase  2  prototype  was  being  built. 
The  first  model,  encoded  fairly  quickly  in  cooperation  with  GCC  and  other  ESC/ENS  personnel, 
was  available  for  an  Initial  Operating  Capability  (IOC)  demonstration  in  late  1991.  The  initial 
model  was  primitive,  but  was  a  useful  demonstration  of  many  of  the  features  of  the  RLF  and 
the  CARDS  Command  Center  Library. 

Release  2.0  of  the  Command  Center  Library  included  a  refinement  of  the  library  model  made 
in  response  to  a  new  release  of  the  operational  library  software.  The  model  was  updated 
substantially,  with  major  changes  to  the  high  level  structure  of  the  command  center  aggregation 
hierarchy,  the  addition  of  the  message  processing  subsystem,  and  an  initial  allocation  of  military 
requirements  to  computational  subsystems  to  produce  the  current  model. 

Release  3.0  of  the  model  retained  the  same  high  level  structure  as  Release  2.0  and  differed 
primarily  by  addition  of  lower  level  concepts  to  represent  new  components. 

Release  3.1  of  the  model  retained  the  same  high  level  structure  as  release  3.0,  with  the  addition 
of  several  new  components  and  aggregational  relationships  for  many  of  the  component  classes. 

Release  3.2  of  the  model  retained  all  of  the  features  of  release  3.1,  with  the  addition  of 
trilateral  interoperability,  interoperability  metrics  and  system  demonstrations.  CARDS  has 
implemented  interoperability  between  CARDS,  ASSET  (Asset  Source  fw  Software  Engineering 
Technology),  and  DSRS  (Defense  Software  Repository  System).  This  addition  has  prompted  the 
addition  of  Sections  3.10,  Interoperability,  and  3.10.,1  Interoperability  Metrics.  The  addition  of 
demonstrations  opens  the  door  for  future  demonstrations  of  various  systems  in  the  library  and 
prompted  the  addition  of  Sections  3.9  System  Demonstrations,  and  3.11.4,  Anticipated  System 
Demonstrations,  to  this  document. 

Release  3.3  of  the  model  reflected  modifications  to  the  Command  Center  Library.  These 
modifications  included  the  addition  of  new  nodes  and  graphical  images,  removing  and  renaming 
various  nodes,  and  adding  and  modifying  selected  relationships  associated  with  specific  nodes. 

Release  4.0  of  the  model  partitions  the  CCL  model  into  smaller,  more  manageable  models.  The 
CCL  was  partitioned  into  seperate  models  in  the  following  manner;  an  architectual  model  which 
contains  the  Architecture  and  Technical  Reference  Model  hierarchies;  a  requirements  model 
which  contains  the  DISA  CCDH  and  TACE  requirements  categories  and  objects;  and  models 
for  each  component  class,  including  sub*component  classes  for  which  there  are  criteria. 

CARDS  will  see  an  increasing  involvement  with  various  organizations  through  partnerships, 
both  of  the  command  and  control  and  other  domains.  The  goal  behind  such  partnerships  is  not 
necessarily  support  for  the  command  center  model,  but  promotion  of  reuse  adoption.  CARDS 
win  also  see  an  increase  of  work  in  the  area  of  architectures  in  two  ways: 

1.  'Fhe  "fleshing"  out  of  the  GCC  architectural  representation. 
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2.  llie  investigation  of  alternative  architectural  views,  including  architectures  other 
than  the  GCC,  and  tools  other  than  the  RLP. 


3.4  Requirements 


The  requirements  section  of  the  model  begins  with  the  requirement  node.  The  requirement 
node  is  the  ancestor  of  all  military  functions  and  activities  required  in  a  command  center.  The 
specializations  in  the  requirement  subtree  divides  requirement  into  disa_ccdh_item  and  tace_item. 
disa_ccdh_item  is  specialized  by  function  and  activity  (Figure  3-1). 

There  are  two  ways  of  looking  at  the  functions  and  activities  in  the  requirements  area  of  a  GC 

(1)  as  functitms  and  activities  that  must  be  contained  by  a  GCC  (acccaxling  to  disa_ccdh) 

(2)  as  a  path  for  finding  activities  ccMtesponding  to  functions  and  the  components  that  must 
utilized  to  perfmm  those  activities. 


Figure  3-1  requirement  concept 
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Figure  3-2  disa_cc(Ui_itcm  function 

Acceding  to  the  DISA  CCDH  [DISA91],  and  augmentation  by  PRISM,  the  military  function¬ 
ality  of  a  command  center  is  divided  into  eleven  basic  functions.  Each  of  these  functions  is 
divided  into  an  arbitrary  number  of  activities,  with  a  total  of  76  activities  (see  Figure  3-2). 

The  DISA  further  breaks  down  each  activity  into  tasks.  These  tasks  are  not  represented  in 
the  current  model  as  they  are  at  a  level  of  detail  not  currently  necessary  for  modeling  purposes. 

Note  the  11  DISA  CCDH  functions  (in  Figure  3-2)  that  must  exist  in  a  command  center.  The 
coiesponding  activities  of  the  fimction  forces_employment_activity  are  shown  in  Figure  3-3. 
These  are  the  activities  that  must  be  performed  to  accomplish  forces_employment  function. 
Figure  3-4  shows  the  aggregational  view  of  the  activity  plan_executi(»i_7_c.  The  links  to  the 
ctnnponents  that  make  up  the  activity  can  be  seen. 
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Figure  3-3  forces_employmcnt_activity 

The  TA/CE  Command  Center  Systems  Architecture  Handbook  [DCA90]  is  another  functional 
decomposititm  of  the  command  center  and  is  represented  by  the  tace.item  in  the  model.  The 
TA/CE  decomposition  is  also  not  represented  in  the  model,  but  the  tace.item  stub  is  present  for 
the  possibility  that  its  functional  decomposititm  of  the  command  center  will  be  included  in  the 
future. 

Most  of  the  activities  are  connected  to  the  software  component  classes  that  implement  them  by 
aggregation  links.  These  links  will  permit  the  system  composititm  tool  to  determine  for  the  user 
which  components  they  need,  based  on  the  us&^s  specification  of  what  military  functionality 
they  wish  to  have. 

3jS  Ardiitectures 


The  CARDS  Command  Cento'  Architecture  is  based  on  the  PRISM  Command  Center  Software 
Architecture.  To  uncover  the  CARDS  architecture,  we  must  first  discuss  the  PRISM  Command 
Canter  design. 
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Figure  3-4  Aggregational  view  of  plan_executi<m_7_c 

PRISM  has  used  the  DoD  Muldcomnuuid  Required  Operational  Capability  for  Command  Cen¬ 
ters  [DOD91]  to  decompose  a  generic  command  center  into  its  constituent  subsystems.  This 
division  ^)ecifies  four  subsystems: 

•  Facility 

•  Communications 

•  Information  Processing 

•  Briefing  and  Display 

The  Facility  Subsystem  includes  such  items  as  furniture,  building  components,  and  the  design 
of  the  functional  spaces,  including  providing  utilities  sudi  as  heat,  light,  power,  etc. 

The  Communications  Subsystem  comprises  the  hardware,  software  and  protocols  required  to 
interconnect  equipment  within  the  command  center  and  to  terminate  external  communication 
links  entering  the  command  center.  This  subsystem  includes  voice  communications  but  excludes 
intra-command  center  communications  covered  by  the  Infcxmation  Processing  and  Briefing  and 
Display  Subsystems. 

The  Information  Processing  Subsystem  (IPS)  is  comprised  of  External  Interfaces,  Networking, 
Mission  Processing,  and  Human-Machine  Interfaces.  The  functionality  of  this  subsystem  is 
expected  to  be  physically  distributed  to  the  extent  permissible  within  security  constraints.  Local 
area  netwrvks  (LANs)  will  exist  in  individual  command  center  work  spaces.  The  number 
and  location  of  servers  and  peripheral  devices  in  various  command  center  work  ^aces  will 
vary  depending  on  security  and  performance  requirements.  Gateways  and  bridges  will  permit 
ccmmunication  among  the  various  LANs  and  with  other  automatic  data  processing  (ADP) 
systems.  The  IPS  is  the  heart  of  the  command  center  model. 

The  Briefing  and  Display  Subsystem  (BDS)  is  comprised  of  graphics  wokstadons,  video  switches 
and  controllers,  large  screen  displays  and  monitexs,  video  teleconferencing,  and  other  audiovisual 
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suppcHt  equipment.  Hie  BDS  is  connected  to  the  backbone  network.  Such  connections  provide 
a  path  for  obtaining  digitized  graphics  developed  on  IPS  workstations.  Direct  connections  from 
selected  IPS  wcn-kstations  to  the  video  switch  permits  presentation  of  the  graphics  on  large  screen 
displays  and  monitors  which  are  located  in  various  work  spaces  throughout  the  command  center. 

As  in  the  previous  version  of  the  CARDS  library,  the  IPS  is  stiU  the  only  subsystem  implemented 
by  PRISM  and  it  is  the  only  subsystem  discussed  in  this  document 


3J.1  The  PRISM  Architecture 


This  section  describes  the  command  center  software  architecture.  The  components  are  grouped 
into  four  sets  of  functions: 

•  External  Interfaces 

•  Missitm  Processing 

•  Human-Machine  Interface 

•  Network  System 

The  relationship  between  the  services  outlined  in  the  previous  section  and  the  functional  areas 
of  the  architecture  is  shown  in  Figure  3-5.  As  can  be  seen  in  this  diagram,  the  functional  areas 
of  the  architecture  are  related  to  the  IPS,  which  itself  depends  upon  both  the  Communications 
and  Briefing  and  Display  Subsystems. 


Figure  3-5  Relationship  between  Component  Architecture  and  Services  Subsystems 
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PRISM’S  software  architecture,  upon  which  Uie  general  architecture  portion  of  the  library  model 
is  based,  is  shown  in  Figure  3-6.  It  is  also  rq)resented  as  a  graphic  image  in  the  CARDS  CCL 
Model.  The  image  is  located  at  die  PRlSM.Architecture  node,  and  can  be  viewed  by  selecting 
the  "Picture  Image"  action  from  the  pqi-up  menu. 

Messages,  in  eitho-  ASCII  w  bit-based  format,  are  rmited  through  the  Interprocess  Communi¬ 
cation  component  to  the  Message  TranslattH*  and  Validator  (MTV),  where  they  are  validated 
and  translated  into  a  ‘vanilla’  SQL  fonnat.  The  translated,  validated  messages  are  submitted  to 
the  Database  Manager  (dirough  the  Database  Broker)  for  entry  into  the  database.  The  Database 
Manager  has  the  ci^ability  to  logically  separate  actual  and  exercise  databases  and  place  informa¬ 
tion  in  t^propriate  tables.  The  (operator  interfaces  with  the  CIS  through  an  X  Window  Interface. 
The  primary  function  for  the  GIS  is  to  provide  the  following  c^abilities; 

•  Present  basic  vecUx'  map  data 

•  Zoom  and  pan 

•  Display  of  near  real  time  tracks 

•  Filter  map  features  (e.g.,  track,  roads,  rivers,  etc.) 

•  Calculate  and  display  beaiing/range  line 

The  cs^ability  to  produce  tables  of  information  through  ad  hoc  queries  is  required  upon  operator 
command  through  the  X  Window  Interface.  The  Table  Generator  is  required  to  produce  SQL 
commands  that  are  routed  through  the  System  Manager  to  the  Database  Manager  and  queried 
results  are  routed  back  to  the  Table  Generate'. 

Finally,  a  Briefing  System  ci^ability  is  imptemented  through  the  X  Window  Interface.  The 
primary  requirements  of  the  Briefing  Display  Subsystem  are  to  have  a  hypermedia  capability; 
to  be  enable  of  producing  charts,  graphs,  and  slide  shows;  and  to  interface  to  the  Database 
Manager  using  SQL.  The  latter  ciq)ability  allows  for  the  automatic  update  of  predefined  charts 
as  in  a  typical  recurring  stand-up  briefing.  Additionally,  the  Briefing  System  is  capable  of 
accepting  scanned  images. 

The  concepts  under  subsystem  represent  large  command  center  subsystems.  Concepts  under 
disa.subsystem  are  the  main  hardware/software  command  center  subsystems  defined  in  the  DISA 
CGDH  including  briefing_display_hardware,  cmnmunications,  facility,  and  ips  (infexmation 
processing  subsystem).  Concepts  under  gcc_group  are  software  subsystems  of  the  ips  that 
were  defined  by  PRISM  including  human_machine_interface,  network^mgt.subsystem,  external, 
interface,  and  mission jf>roce8sing.  As  in  Version  3.2  of  the  library,  only  these  ips  subsystems 
have  been  modeled  in  any  great  detail. 
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3.6  Component  Class  Models 

Each  component  class  is  modeled  using  a  standard  OTgankation.  There  are  three  major 
classifications  for  the  information:  1)  features  fo*  that  particular  component  class,  2)  architectural 
constraints  and  3)  implementation  constraints.  For  each,  there  is  a  relationship  between  the 
component  class  and  the  criteria.  The  criteria  are  specified  as  either  categories  or  objects 
organized  into  a  semantic  network. 

3.6.1  Features  for  that  particular  component  class 

These  features  are  functions  the  component  class  should  perform  with  respect  to  a  command 
center.  There  are  features  which  are  required  and  those  which  are  optional.  For  example,  a 
feature  of  a  word  processor  is  that  it  should  gen^ ate  a  table  of  contents. 

In  the  CCL,  these  criteria  can  be  found  under  the  feature  tree.  Features  which  may  be  common 
among  component  classes  are  normally  modeled  as  direct  children  of  the  feature  categtx^.  Others, 
more  specific  to  a  component  class,  may  have  a  parent  indicating  the  component  class  to  which 
they  belong.  For  example,  features  unique  to  a  spreadsheet  exist  under  a  category  named, 
ss_feature  (spreadsheet  feature)  (Figure  3-7). 


Figure  3-7  Spreadsheet  Feature  Tree 


3.6.2  Architectural  constraints 

This  set  of  criteria  indicates  how  the  component  classes  fit  together  to  form  a  command  center 
architecture.  For  instance,  a  briefing  system  must  be  able  to  accept  data  from  a  word  processor.  In 
addition,  where  required,  the  oiteria  indicate  how  those  connections  should  be  implemented.  Fm* 
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instance,  a  briefing  system  should  be  able  to  accept  data  from  a  wcH-d  processor  via  interprocess 
communication. 

These  criteria  are  modeled  as  relationships  among  component  classes.  They  may  appear  also  as 
children  under  the  application_platform_specification  tree  (Hgure  3-8). 


Figure  3-8  ^plication  Platform  Specification  Tree 


3.63  Implementation  constraints 

This  set  of  criteria  specifies  the  supp<»^g  hardware  and  software  required  for  the  comfxonent 
class.  An  example  of  a  hardware  constraint  may  be  that  the  component  must  run  on  the  Sun 
platform.  An  example  of  a  software  constraint  may  be  that  the  component  must  run  under  XI 1 
Release  4. 

In  general,  hardware  constraints  are  modeled  under  the  hardware  tree  (Figure  3-9)  and  software 
constraints  under  the  application^latfarm.software  tree  (Figure  3-10). 


Figure  3-9  Hardware  Tree 
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Figure  3-10  Application  Platform  Software  Tree 

Features  and  constraints  are  either  required  by  the  command  center  (critical  features  or  con¬ 
straints)  or  (q>tional  to  the  cmnmand  center.  A  critical  criterion  will  have  a  relationship  range 
of  at  least  one  as  the  minimum  [may  want  to  make  a  reference  to  the  RLF  Modeler’s  Manual 
Qiapter’s  3  and  4],  For  example,  a  critical  criterion  for  wad  processa’s  with  respect  to  a  com¬ 
mand  center  is  the  ability  to  generate  a  table  of  contents.  That  would  be  modeled  as; 

•  does_j5enerate_table_of_contents  (1  ..  1)  of  table_of_contents; 

A  non-critical  criterion  will  normally  have  a  relationship  range  of  zero  as  the  minimum.  For 
example,  a  non-critical  criterion  for  word  processor’s  is  the  ability  to  create  a  table.  That  would 
be  modeled  as: 

•  creates_table  (0  ..  1)  of  table. 
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3.7  Qualified  Components 


Figure  3-11  component.class  and  its  children 

Component  qualification  (see  Figure  3-7)  is  the  process  of  acquiring  and  evaluating  compo¬ 
nents  for  a  domain  specific  library.  The  components  are  qualified  as  to  whether  they  fit  within 
a  particular  domain.  The  emphasis  is  on  supporting  domain  requirements.  The  component  is 
classified  as  to  what  subsystem  of  the  generic  architecture  it  satisfies.  Components  are  mea¬ 
sured  against  domain  criteria,  which  are  measurements  of  form,  fit  and  function  implied  to  the 
command  center  domain.  These  are  a  composite  of  domain,  architecture  and  implementation 
constraints.  Components  are  also  considered  by  domain  independent  aspects  of  common  criteria 
such  as  perfontnance,  reliability,  maintainability,  etc.  After  the  components  have  been  qualified, 
they  are  placed  under  cQmponent_class  category. 
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3.7.1  DBMS 

The  Database  Management  System  (DBMS)  stores  and  manages  tables  of  data  the  command 
center  will  query  and  modify  during  daily  activities.  The  Database  Manager  should  support  a 
relational  data  model  and  a  client/server  architecture.  The  important  and  widely  used  large  scale 
database  products  now  support  the  client/server  architecture. 

The  DBMS  (Figure  3-8)  has  performance  constraints  placed  upon  it  by  a  command  center 
which  must  be  met.  An  example  of  a  performance  requirement  is  from  SAFWCCS;  a  database 
managa'’s  response  time  must  not  exceed  two  (2)  seconds  when  perfuming  any  single  data  table 
transaction. 


Figure  3-12  DBMS  and  its  children 

3.7.1.1  Ingres 

Ingres  represents  release  6.4  of  a  relational  database  management  system  (RDBMS)  developed 
by  Ingres  Corporation.  The  RDBMS  has  been  in  release  since  1983  and  about  50,000  licenses 
have  been  granted.  Ingres  provides  batch,  stored  procedures,  and  interactive  Structured  Query 
Language  (SQL)  data  access  and  manipulation. 

Ingres  also  provides  mutual  exclusion  provisions  to  provide  concurrent  data  access.  The  default 
and  lowest  level  locking  for  Ingres  is  page  level.  Ingres  employs  locking  at  various  levels; 
however,  the  only  locks  subject  to  user  control  are  at  the  table  and  page  levels.  Predefined 
access  restrictions  are  provided  to  allow  application  programs  to  concurrently  read  and/or  write 
a  shared  database.  Provisions  are  available  f<x  the  owner  of  a  database  to  restrict  all  or  part  of 
the  data  in  the  database.  Ingres  also  provides  automatic  full  and  partial  dump  facilities,  and  the 
ciq)ability  for  several  application  programs  to  concurrently  read  and/or  write  the  shared  database 
subject  only  to  predefined  access  restrictions.  Provisions  are  made  f(x  the  owner  of  a  database 
to  restrict  access  to  aU  ch*  part  of  the  data  in  the  database. 

References  to  security  issues  are  sparse;  howevo-,  the  vendor  claims  that  Ingres  has  substantial 
Command  Center  (C2)  features,  and  that  the  next  release  will  have  full  C2  features.  Ingres 
provides  physical  and  logical  separation  of  data  at  different  security  classification  levels. 

In  the  CARDS  library  the  following  are  available  f(x  the  component  Ingres: 

*  Product  evaluation  reports  in  ASCII  and  postscript  formats 
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•  Product  assessment  on  line  in  model 

•  Product  description  in  ASCII  format 

3.7.U  Grade 

Oracle  represents  release  7  of  a  RDBMS  developed  by  Oracle  Corporation.  The  Oracle  RDBMS 
has  been  in  release  since  1978  and  approximately  400,000  licenses  have  been  granted.  Oracle 
provides  support  to  over  80  platforms. 

Oracle?  provides  batch,  stored  procedure,  and  interactive  SQL  data  access  and  manipulation, 
and  integrity  constraints  and  triggers  as  solutions  to  managing  data  base  data  integrity  rules.  It 
implements  locks  to  prevent  destructive  interaction  between  users  accessing  the  same  resource. 

Ch-acle?  and  Trusted  Oracle  (Oracle?  with  multi-level  security)  comply  with  the  National 
Computer  Secinity  Center’s  C2  and  B1  Orange  Book  Security  Criteria  levels,  respectively. 
Oracle?  provides  extensive  auditing,  allowing  the  auditing  of  data  accesses,  successes  and 
failures,  and  logons. 

Oacle?  supports  dient/servo*  operation,  a  dedicated  server  architecture  in  which  every  user 
proce^  connected  to  Oracle?  has  a  corresponding  server  process,  a  multi-threaded  architecture 
in  which  a  small  number  of  shared  server  processes  can  perform  the  same  amount  of  processing 
that  would  otherwise  be  done  by  many  dedicated  server  processes,  distributed  processing,  location 
transparency,  netw^k  transparency,  and  On-Line  Transaction  Processing. 

In  the  CARDS  library  the  following  is  available  fcx  the  component  Oracle: 

•  Product  evaluation  repents  in  ascii  and  postscript  formats 

•  Product  assessment  on  line  in  model 

•  Product  descriptieni  in  ascii  format 

3.7.2  Briefing  Syston 


MifiBt.fyfMB 


Figure  3-13  Briefing^system  and  its  child 

Briefing  s;^tem  (Figure  3-9)  is  a  class  of  components  facilitating  the  generation  of  textual  and 
graphical  {nesentations  on  screen  or  paper.  These  components  use  mission  data  from  command 
center  databases  to  create  bar  charts,  pie  charts  and  other  decision  support  displays  for  operations 
briefings. 
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3JX1  Lotiis^l23 

Lotus  1-2-3  is  a  commercial  briefing  system  software  package  allowing  use's  to  create 
spreadsheets  of  data  and  display  them  as  spreadsheets,  charts,  or  graphs.  Lotus  1-2-3  offes 
up  to  256  pages  of  data,  built-in  functions  and  3-D  charting  capability. 

In  the  CARDS  library  the  following  are  available  for  the  component  Lotus_123  as  a  briefing 
system; 


•  Product  evaluation  reports  in  ASCII  and  postscript  framats 

•  Product  assessment  on  line  in  model 

•  Product  description  in  ASCII  femat 
3.7.3  Database  User  Interface 


I 

I 


Figure  3-14  Database_User_Interface  and  its  descendants 

A  database  user  interface  (Figure  3-10)  provides  a  means  for  the  user  to  interact  with  the  database 
engine.  A  typical  graphical  user  interface  may  provide  the  user  with  menus,  buttons  and/or  icons 
with  which  to  access  the  database. 

3.7.4  Database  Front-End 

The  database  front-end  is  used  to  query  the  database  and  produce  reports  on  the  database  tables. 
A  database  front-end  provides  an  interface  for  the  operator  of  a  database  to  generate  structured 
quay  language  commands.  The  database  front-end  should  be  able  to  support  ad-hoc  queries  to 
the  database.  The  database  front-end  is  responsible  for  the  look  and  feel  of  the  queries  to  the 
database.  The  database  front-end  also  interfaces  with  the  qperational  database  through  a  database 
broker. 

The  database  front-end  should: 

•  Provide  tools  for  creating  a  robust  application  interface. 

*  Provide  basic  transparent  data  handling,  such  as  automatically  creating  default  forms 
based  on  ousting  tables. 
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•  Simplify  menu  creation  and  maintenance. 

•  Make  it  easy  U>  inctHporate  SQL  queries  in  an  application. 

•  Provide  a  rq)ort  layout  facility  that  lets  the  user  easily  a-catc  a  rcptHt. 

•  l^ovide  debugging  utilities. 

•  Have  satisfactory  response  times. 

3.7.5  Multi'Database  Database  Frontend 

A  multi-database  database  front-end  can  access  multiple  database  management  systems. 

3.75.1  SmartStar 

SmaitStar  Vision  is  a  wm-kstation-based  software  environment  for  developing  "Motif-to-SQL" 
database  applicatitms  with  litde  or  no  coding.  It  was  developed  by  SmartStar  Ccxporation  and 
has  been  in  release  since  November  1992. 

The  applicaticm  development  environment  is  very  impressive.  In  addition  to  the  usual  Interactive 
SQL  (ISQL),  3rd  Generation  Language  (3GL)  library  interface,  and  4th  Generation  Language 
(4GL),  SmartStar  Vision  contains  "NoGL."  "NoGL"  enables  a  user  to  create  a  Graphical  User 
Interface  (GUI)  databases  without  SQL,  3GL,  or  4GL.  It  uses  menus,  buttons,  and  icons.  Once 
taught  about  the  basics  of  what  a  database  is,  even  the  most  inexperienced  user  could  create 
effective  databases. 

SmartStar  Vision  allowed  databases  to  be  develtped  independent  of  the  physical  database  type(s) 
in  use.  This  was  accomplished  using  SmartStar  Vision’s  ANSI-SQL  database  called  Logical 
Database  (LDB).  The  LDB  dictionary  stores  logical  mappings  to  tables  in  data  hies  or  physical 
databases. 

SmartStar  Vision  currently  supports  Oracle,  Sybase,  and  Ingres  database  management  systems. 
SmartStar  Vision  was  evaluated  in  conjunction  with  Sybase. 

SmartStar  Vision  suppmts  both  user  interface  and  database  client/server  connection.  SmartStar’s 
GUI  client/server  supptxt  enables  any  X-compatible  device  to  display  SmartStar  Vision  running 
on  another  computer  through  a  remote  login. 

In  the  CARDS  library  the  following  are  available  fa:  the  component  smartstar; 

•  Product  evaluation  reports  in  ASCII  and  postscript  fcxmats 

•  Product  assessment  on  line  in  model 

•  Product  description  in  ASCII  format 
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3.7.6  Mapping  System 


Figure  3-lS  mapping_sysuan  and  its  descendants 

A  mq)ping  system  (Hgure  3*11)  is  a  component  class  designed  primarily  for  the  display  and 
man4>ulation  of  spatial  data  and  infcumation. 

3.7.61  OILSTOCK 

0ILSTCX3C  is  a  high  resolution  interactive  graphics  system.  In  addition  to  data  display,  analysts 
can  draw  geopositional  overlays  on  OILSTOCK  maps  to  produce  repots  or  amplify  information. 
OILSTOCK  uses  the  CIA  World  Database  II  (WDBII)  as  its  foundation  for  vector  maps  and 
the  Defense  Mq>ping  Agency’s  (DMA)  ARC  Digitized  Raster  Graphics  for  high  quality  raster 
mips.  OILSTOCK  reads  Digital  Terrain  Elevation  Data  to  conduct  a  visual  line  of  site  analysis. 

Advanced  features  include  EUNT/Direction  Finding  capabilities  and  calculating  satellite 
footprints.  OILSTOCK  also  supports  cartogrq>hic  overlays  and  numerous  mip  projections.  In 
particular,  OILSTOCK  is  designed  to  track  airlxHne  targets,  including  aircraft  and  satellites,  and 
seagcwg  vessels. 

OILSTCXIK  is  accompanied  by  excellent  hard-copy  manuals,  making  it  easy  to  install  and 
evaluate.  The  organization  of  the  manuals  makes  them  easy  to  use  as  a  reference  and  a  tutorial. 

In  the  CARDS  library  the  following  are  available  for  the  component  OILSTOCK: 

•  Product  evaluation  reprxts  in  ASCII  and  postscript  formats 

•  Product  assessment  on  line  in  model 

•  Product  descripti(»i  in  ASCH  format 
3.7.7  Geographic  Information  System 

A  Cjeograpfaic  Information  System  (GIS)  is  used  for  presenting  and  manipulating  information  in 
a  geographical  context.  In  basic  terms,  GIS  links  tabular  data  as  found  in  a  traditional  database 
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with  the  visual  world  of  and  charts.  This  has  proven  to  be  an  efficient  method  of  analyzing 
data  and  is  becoming  very  wide-spread. 

CIS  comes  in  basically  two  graphic  fcxmats:  vector  and  raster.  Each  type  is  used  to  solve  dif¬ 
ferent  types  of  problems.  Vectcx'  data  is  easily  scaled  and  identified.  It  is  simple  to  select  vectCM- 
features  to  be  displayed,  while  ignoring  unwanted  data.  Unfortunately,  vector  data  is  very  ex¬ 
pensive  to  collect  and  encode. 

Raster  data,  on  the  other  hand,  is  inexpensive  to  produce,  since  it  basically  consists  of  scanned 
pixels  of  data.  The  data  looks  real,  or  at  least  as  real  as  the  source  of  the  data.  It,  too,  has  its 
disadvantages,  in  that  it  is  expensive  to  store  and  virtually  impossible  to  update  wiUunit  adding 
rescanned  images.  The  ability  to  support  both  vector  and  raster  processing  has  greatly  increased 
the  usefulness  of  GIS  and  has  fueled  its  wide-spread  use  and  inacased  availability  in  recent 
years. 

A  GIS  should  provide  the  ability  to  add  well-defined  standard  symbols  to  2-  and  3-dimensional 
maps,  and  provide  tools  to  perform  analysis  on  both  the  maps  and  added  symbols.  Typical 
analysis  requires  polygon  overlay,  netwcx-k  routing,  address  geocoding,  and  spatial  statistics. 
Communicating  with  a  database  is  necessary  to  add  dynamic  and  static  data  to  the  view  of  the 
map. 

Many  GISs  can  also  interface  with  output  from  computer  aided  design  (CAD)  systems  and 
existing  tabular  data. 

3.7.7.1  GRASS 

GRASS  is  a  public  domain  GIS  that  is  popular  within  both  the  government  and  academic 
communities.  It  was  originally  developed  by  the  Construction  Engineering  Research  Laboratory 
of  the  United  States  Army.  Originally  designed  for  resource  analysis,  it  has  since  been  expanded 
and  extended  to  perform  a  wide  variety  of  applications  involving  the  display,  manipulation,  and 
analysis  of  spatial  data. 

The  primary  advantages  of  GRASS  are  its  display  and  analysis  capabilities;  and  its  ability  to 
be  extended  and  used  in  a  variety  of  methods.  GRASS  is  comprised  of  two  modules:  a  C 
function  library  and  a  stand-alone  system.  Both  provide  a  large  degree  of  functionality  and  can 
be  extended  either  through  a  client  application  with  the  function  library  or  by  develt^ing  custcun 
commands  via  the  stand-alone  environment. 

The  flexibility  of  GRASS  makes  it  an  excellent  addition  to  a  CCL  because  of  the  diverse  and 
critical  requirements  of  a  command  center. 

In  the  CARDS  library  the  following  are  available  for  the  component  grass: 

•  Product  evaluation  reports  in  ASCII  and  postscript  ftxmats 

•  Product  assessment  on  line  in  model 


Product  description  in  ASCII  format 
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•  Product  source  code 

3.7  J  Mem^ee  TranslatorA^alidator  Generator 


*  Figure  3-16  message_translater_validator_generatQr  and  its  child 

H  The  message  transkta/validator  generator  (Rgure  3-12)  is  a  component  class  that  produces 

other  cmnponents.  This  particular  node  produces  or  generates  systems  that  perform  the  tasks 
of  message  translatCHS  and  validators.  Typically  generators  produce  source  code  and  it  is  then 
the  responsibility  of  the  application  developer  to  compile  the  code  and  perform  any  necessary 
integration. 

3.7.8.1  GBMV 

The  GCCA  specifies  a  component  for  message  translation  and  validation  (MTV),  for  the 
processing  of  encoded  messages.  The  Grammar  Based  Message  Validator  (GBMV)  provides 
the  validation  functionality,  aeating  validators  capable  of  processing  character-based  encoded 
messages.  Users  of  the  GBMV  can  produce  validators  for  a  wide  range  of  character-based 
message  formats,  with  little  traininf  and  a  basic  knowledge  of  regular  expressions. 

The  GBMV  runs  under  UNIX  and  incorporates  the  Ada-based  compiler  generation  tools  Afiex 
and  Ayacc,  developed  at  the  University  of  California  -  hrvine.  An  Ada  compiler  is  required  for 
the  compilation  of  these  tools,  and  for  the  compilation  of  the  validator  code  generated  by  the 
GBMV. 

In  the  CARDS  library  the  following  are  available  for  the  component  GBMV: 

•  Product  evaluation  reports  in  ASCII  and  postscript  formats 

•  Product  assessment  on  line  in  model 

•  Product  description  in  ASCII  format 

•  Product  source  code 

•  Product  test  executable  code 

•  Product  user  manual  in  postscript  format 

I 
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3.7.9  Networii  Manager 


-P 


Figure  3*17  netw(x:k_manager  and  its  child 

A  network  manager  (Figure  3*13)  is  a  component  class  designed  primarily  for  the  traddng.  man¬ 
agement  and  ctmtrol  over  physical  and  local  netwcM-k  resources  connected  together  via  a  LAN. 


3.7.9.1  XNetManager 

XNetManager  is  a  package  of  public  domain  software  components  and  enhancements  to  suppcHt 
die  five  majm-  functional  areas  of  network  management  required  by  the  GCCA:  fault  management, 
ctmfiguration  management,  accounting  management,  perfomance  management,  and  security 
management.  XNetManager  vl.O  is  comprised  of  three  public  domain  packages:  Xnetdb-v2.10 
from  the  Ohio  State  University,  XNetmon-vl.O  from  the  Delft  University  of  Technology  of 
Holland  and  xnetmon-vl.l  from  the  University  of  Wisconsin. 

XNetManager  has  proven  to  be  functionally  a^uate  for  a  portion  of  netwcMrk  management  for 
a  GCCA  based  on  the  requirements  set  forth  by  the  domain  criteria.  XNetManager  provides 
many  basic  functions  of  netwwk  management,  specifically  in  the  areas  of  fault  and  perfmmance 
management,  and  is  deemed  an  adequate  tool  for  assisting  the  netwra-k  qieration  manager  (x 
system  administratar  in  getting  a  handle  on  an  operational  local  area  netwwk. 
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3.7.10  Office  AutomatUm  Software 


Figure  3-18  office_automation_software  and  its  descendants 

Office  Automation  (Figure  3-14)  is  an  augmentation  to  the  main  mission  support  capabilities 
and  includes  applications  such  as  word  processing,  spreadsheets,  and  graphics  generation.  It  is 
able  to  interface  to  the  database  and  other  internal  management  information  systems.  This  com¬ 
ponent  may  be  used  in  conjunction  with  the  briefing  preparation^resentation  oc  other  mission 
operations.  It  also  provides  electronic  transfer  of  informal  user  messages  e-mail  over  prescribed 
LAN  segments.  It  includes  functions  such  as  mail  storage,  retrieval,  mail  broadcast,  etc. 


3.7.11  Electronic  Mail  Software 

Electronic  mail  (e-mail)  is  a  required  office  automation  function.  It  permits  routing  of  incoming 
mail  based  on  ctmtrols  established  by  supervisory  personnel  using  plain  English  addresses.  The 
e-mail  compoiMnt  must  be  able  to  support  different  file  types  from  within  the  same  message. 
This  includes  ASCII,  graphics,  scanned  images,  FAX,  spreadsheets,  CAD  drawings,  and  binary 
files.  Other  functions  includes  the  capability  to: 

•  Designate  different  user  classes  and  access  levels. 

•  Locate  stored  messages  by  sender,  receiver,  keyword  search,  or  text  string. 

•  Set  up  bulletin  boards,  LAN-wide  aliases,  and  distribution  lists. 
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There  are  two  basic  sub-processes  of  e-mail  that  implement  these  various  capabilities: 

1.  Message  Transfer  Agent  (MTA)  -  This  process  is  responsible  for  the  actual  transmis¬ 
sion  and  recq>tion  of  mail  messages  across  the  netwcn-k  (both  internal  and  external). 

2,  User  Agent  Process  (UAP  or  UA)  -  TTiis  process  is  the  ffont-eiKl  or  user  interface  to 
the  MTA. 

3.7.12  Message  Transfer  Agent 

An  e-mail  MTA  is  responsible  for  transptxting  mail  from  sources  to  destinations,  possibly 
transfmming  protocols  and  addresses,  and  routing  the  mail  to  the  ^propriate  recipients. 

The  MTA  often  has  several  components: 

•  Routing  mechanisms 

•  Local  delivery  agent 

•  Remote  delivery  agent 

Many  MTA’s  have  all  of  these  components.  In  other  cases,  it  is  possible  to  replace  certain 
components  for  increased  functionality. 

3.7.12.1  PP 

PP  is  a  public  domain  message  transfer  agent  in  the  e-mail  component  class,  intended  for  high 
volume  message  switching,  protocol  conversion,  and  format  conversion.  PP  supports  the  1984 
and  1988  versions  of  the  CCl  Ti  X.400  services  and  protocols.  Many  existing  RFC  822  based 
protocols  are  also  supplied,  along  with  RFC  1 148  conversion  to  X.400. 

PP  is  an  appropriate  rq>lacement  for  traditional  UNIX  MTAs  such  as  MMDF  (Multichannel 
Memo  Distribution  Facility)  or  sendmail. 

With  a  clean  interface  for  message  submission  and  delivery  (e.g.,  suppmt  for  both  MMDF  and 
sendmail  style  mailboxes),  most  widely  available  MTAs  work  in  conjunction  with  PP  to  provide 
a  fully  functional  e-mail  system.  It  was  specifically  tested  and  wOTked  well  with  Z-Mail  (see 
section  3.6.13.1),  MH  (with  and  without  the  metamail  MIME  patches).  XMH  (with  and  without 
the  metamail  MIME  patches),  sendmail,  elm,  xmail,  and  OpenWindows  mailtool. 

In  the  CARDS  library  the  following  are  available  for  the  component  PP: 

•  Product  evaluation  reports  in  ASCII  and  postscript  formats 

•  Product  assessment  on  line  in  model 
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•  Product  descr^don  in  ASCII  fcnntt 

•  Product  source  code 
3.7.13  User  Agent 

An  e-mail  user  agent  (UA)  is  the  user  interface  to  the  e-mail  system  and  minimally  provides 
the  functionality  required  to  view  incoming  mail  and  compose  outgoing  messages.  In  suppmi  of 
these  functions,  the  UA  must  be  able  to  delete,  print,  store,  rqjly  to,  and  forward  mail  messages. 

User  agents  typically  have  additional  support  for  mail  manipulation,  including  sorting,  folder 
qperations,  and  keyword  searches  of  message  content.  More  advanced  features  include 
reading/composing  mail  messages  containing  arbitrary/non-text  data  (attachments),  modifying 
headers,  notifying  the  sender  when  the  receiver  has  read  the  mail,  etc. 

3.7.13.1  zmail 

Z-Mail  is  a  UA  of  the  e-mail  class  of  components  maintained  by  Z-Code  Software  Ccxrp<»ration 
in  San  Rafael,  CaUfomia. 

Z-Mail  provides  extensive  message  composition  capabilities,  including  the  ability  to  include  file 
formats  such  as  binary,  PostScript,  bitmap,  fax,  and  audio  with  a  mail  message.  Z-Mail  also 
provides  useful  message  searching  and  smting  ciq>abilities:  users  can  search  for  patterns  within 
the  messages  or  search  for  messages  based  on  single  or  multiple  expressions.  Actions  can  then  be 
taken  on  those  messages  matching  the  expression(s).  Messages  can  also  be  smrted  in  ascending 
or  descending  order  on  multiple  keys. 

Z-Mail  offers  a  scripting  language,  Z-Script,  for  creating  message  filters  and  other  functions  that 
help  to  automate  management  of  mail.  Z-Script  allows  a  uso*  to  create  custom  defined  buttons, 
user  defined  functions,  and  attach  Z-Script  to  a  mail  message. 

Some  other  important  features  of  Z-Mail  include:  the  abilify  to  perfnm  any  action  rni  a  group 
(tagged)  of  messages,  on-line  help,  the  ability  to  issue  shell  commands  h:om  within  the  mailer, 
notification  to  the  sender  that  a  message  has  been  received,  font  editing,  and  colcx  editing. 

In  the  CARDS  library  the  following  are  available  for  the  component  zmail: 

•  Product  evaluation  reptwts  in  ASCII  and  postscript  formats 

•  Product  assessment  on  line  in  model 

•  Product  description  in  ASCII  format 
3.7.13J  XMH 

XMH  is  an  e-mail  UA  whose  basic  configuration  consists  of  two  public  domain  packages,  MH 
and  xmh.  MH  is  a  text-based  user  agent,  while  xmh  provides  an  X-based  user  interface  to  MH. 
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MH  differs  from  typical  UAs  in  that  all  of  its  commands  are  separate  executables,  providing  the 
ability  to  execute  MH  commands  from  UNIX  shell  programs  and  source  code,  xmh  provides 
graphical  user  interface  (GUI)  functionality  by  making  calls  to  the  MH  programs. 

Two  other  packages,  metamail  and  xlbiff,  have  been  identified  for  use  in  conjunction  with  XMH 
to  provide  required  functionality.  Metamail  converts  XMH  into  a  MIME  (Multipurpose  Internet 
Mail  Enhancements)  compliant  multimedia  UA  (although  message  creation  is  supported  only  in 
the  text  mode),  xlbiff  alerts  the  user  of  new  mail. 

Standard  user  agent  functionality  is  supported,  including;  viewing,  creating,  forwarding,  replying 
to,  printing  and  deleting  mail;  folder  operations  (creating,  opening,  saving  mail  to),  and  tagging 
messages  for  group  operations.  XMH  also  supports  sequences  -  associating  a  group  of  messages 
with  some  name  based  on  characteristics  of  those  messages. 

Metamail  provides  the  ability  to  include  arbitrary,  non-text  data  in  a  mail  message.  A  message 
can  be  separated  into  multiple  parts,  and  transmitted  as  separate  mail  messages.  Another  notable 
feature  is  that  of  including  "pointers"  to  data  instead  of  the  data  itself  (e.g.,  a  file  at  a  remote 
site),  metamail  will  retrieve  the  data  when  the  message  is  read. 

As  ftx  architectural  constraints,  XMH  has  direct  MTA  support  for  MMDF  (Multichannel  Memo 
Distribution  Facility),  MMDF-II,  sendmail,  and  zmailer.  MTAs  providing  interfaces  based  on 
these  four  transfer  agents  will  also  work  with  XMH. 

In  the  CARDS  library  the  following  are  available  for  the  component  XMH: 

*  Product  evaluation  reports  in  ASCII  and  postscript  formats 

*  Product  assessment  on  line  in  model 

*  Product  description  in  ASCII  format 

*  Product  source  code 

3.7.14  Spreadsheet 

Spreadsheet  is  a  component  class  facilitating  the  entry  of  tables  of  numbers.  Spreadsheets  allow 
users  to  specify  equations  that  calculate  other  table  entries  based  on  the  user  input  Spreadsheets 
often  allow  users  to  aeate  bar  charts,  pie  charts  and  other  graphical  presentations  of  selected 
data  from  the  numerical  tables. 

3.7.14.1  Xspread 

Xspread  is  a  public  domain  spreadsheet  based  on  the  spreadsheet  driver  program  SC.  It  was 
developed  at  the  Univmity  of  Wisconsin  at  Milwaukee.  There  is  help  available,  documentation, 
source  code  and  an  fq)-site  listing  on-line. 
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Ill  the  CARDS  library  the  fdli^idiig  are  available  for  the  cimipcment  xs{H‘ead: 

•  Product  evaluatirai  rqxirts  in  ASCII  and  postscript  formats 

•  Product  assessment  on  line  in  model 

•  Product  description  in  ASCII  format 

•  Product  source  code 

3.7.14^  lotusl23  (spreadsheet) 

lotusl23  is  a  commercial  spreadsheet  software  package.  This  package  allows  the  user  to  create 
spreadsheets  of  data  and  display  them  as  spreadsheets,  charts,  or  graphs.  Iotusl23  offers  up  to 
256  pages  of  data,  built-in  functions  and  3-D  charting  cqiability. 

In  the  CARDS  library  the  following  are  available  for  the  component  lotusl23  as  a  spreadsheet 

•  Product  evaluation  repmis  in  ASCII  and  postscript  formats 

•  Product  assessment  tm  line  in  model 

•  Product  description  in  ASCII  format 

3.7.14  J  wingzjss 

Wingz  is  a  commercial  spreadsheet  package.  It  has  very  extensive  graphic  cq>abilitie$  with 
3-D  imaging  available  as  well  as  a  Hyperscr4>t  language  to  enhance  user  documents.  Wingz  is 
available  for  all  the  major  gri^hical  interfaces,  making  it  very  ptxtable  and  usable. 

In  the  CARDS  library  the  fallowing  are  available  for  the  component  wingz.ss: 

•  Product  evaluation  reports  in  ASCII  and  postscript  formats 

•  Product  assessnwnt  on  line  in  model 

•  Product  descr4)ti(m  in  ASCII  format 

3.7.15  Word  Processor 

A  word  processcHT  allows  for  the  creation  and  modification  of  textual  documents.  Capabilities 
normally  include  importation  of  graphics,  setting  of  fcmt  styles  and  sizes,  creation/modification  of 
paragn4>h  formats,  etc.  The  most  common  form  of  interacting  with  a  word  processm  is  through 
a  WYSIWYG  (What  You  See  Is  What  You  Get)  style  of  graphic  user  interface.  Many  common 
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fonnats  exist  for  storing  documents  created  with  word  processors.  These  include;  PostScript, 
Standard  Generali^  Nbrkup  Langua^  (SGML),  EDI,  and  other  vendor  specific  formats  along 
with  ASCn. 

3.7.15.1  Arbortext 

The  Arbortext  ADEPT  Series  provides  a  structured  approach  to  documentation  preparation.  The 
ADEPT  Series  includes  two  products  aimed  at  structured  document  preparation; 

•  SGML  Editm*  -  a  text  editw  fcr  creating  and  editing  SGML  documents. 

•  SGML  Publisher  -  provides  the  same  tools  as  the  SGML  Editor,  but  adds 
previewing  and  printing  capabilities. 

In  the  CARDS  library  the  following  are  available  for  the  component  arbortext; 

•  Product  evaluation  refKXts  in  ASCII  and  postscript  formats 

•  Product  assessment  on  line  in  model 

•  Product  descripticHi  in  ASCII  format 


3.7.16  Desktop  Publisher 

Desktq)  publishing  systems  are  similar  in  usabilities  to  word  processors  but  with  advanced 
features.  Some  of  these  advanced  features  include;  the  capability  to  creaWedit  graphic  figures 
and  images  within  the  system,  and  functionality  for  layout  of  the  document. 

3.7.16.1  FrameMaker 

FrameMaker  is  a  Commercial  Off  The  Shelf  (COTS)  component  facilitating  WYSIWYG  creation 
of  formatted  rep<xts  with  embedded  graphics.  FrameMaker  is  an  advanced  publishing  tool  that 
integrates  word  processing,  graphics,  page  layout,  and  book  building.  It  also  allows  users  to 
import  various  document  and  graphics  formats. 

In  the  CARDS  library  the  following  are  available  for  the  component  FrameMaker; 

•  Product  evaluation  reptxis  in  ASCII  and  postscript  formats 

•  Product  assessment  on  line  in  model 


Product  description  in  ASCII  format 
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3^  Reference  Model 

In  the  structural,  AdaKNET  portion  of  the  model,  the  model  closely  reflects  the  generic 
architecture  established  by  PRISM  along  with  requirements  information  from  the  DISA  CCDH 
[DISA91].  What  has  changed  is  the  way  hardware  and  software  components,  that  provide 
services  to  higher  level  application  software,  are  organized.  This  new  organization,  called  an 
application  platform,  was  derived  from  the  PRISM  Technical  Reference  Model  (Figure  3-15) 
which  is  based  on  the  NIST  Applications  Portability  Profile  [NIST]  and  the  DoD  Technical 
Reference  Model  [DOD92]. 

The  graphic  image  of  the  PRISM  Technical  Reference  Model  is  also  available  fcx-  viewing  in 
the  CARDS  CCL  Model.  The  image  is  located  at  the  PRISM_TRM  node  and  is  produced  by 
selecting  the  "Picture  Image"  action. 

The  concepts  under  application_platfcxm_entity  (Figure  3-16)  provide  services  to  higher  level 
applicatitm  software.  The  application  platform  or  technical  reference  model  foms  a  basis  for 
defining  an  architecture  permitting  interchangeability  of  components  within  subsystems.  One 
main  category  of  the  iq>plicati<Hi  platfcam  is  application_platfOTm_specification  which  includes 
standards  for  operating  systems,  networking,  text  and  graphics  formats,  and  user  interfaces, 
etc.  The  other  categCH^,  application_platf(xm_software  consists  of  software  components  which 
implement  the  standards  and  specifications. 
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Figure  3-19  PRISM  Technical  Reference  Model 
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Figure  3-20  application_platforin_entity  and  its  descendants 


3.9  System  Composition 


One  of  the  main  purposes  of  a  domain  model  is  to  capture  information  that  will  help  a  software 
engineer  build  a  system.  In  CARDS,  the  capability  to  interactively  build  a  system  from  reusable 
components  by  capitalizing  on  information  in  the  domain  model  is  called  system  composition. 
The  approach  used  in  the  CARDS  system  composition  tool  is  a  form  of  knowledge-based  software 
engineering.  Rules  for  composing  a  system  are  written  in  CLIPS  [GIAR92].  The  system 
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composition  tool  uses  these  rules  to  query  AdaKNET.  It  infers  pertinent  questions  to  ask  the 
user.  It  uses  the  answers  to  compose  the  chosen  system. 

The  CARDS  system  compositimi  tool  performs  system  compositiOT  on  the  message  processing 
subsystem  portion  of  Release  3.3  of  the  library,  and  is  invocable  direcdy  from  the  library.  Die 
following  discussion  describes  the  basic  operation  of  this  tool; 

•  The  tool  elicits  information  from  the  user  as  to  what  system  fimctionality  is  required. 
These  questions  are  based  on  information  about  message  processing  comporents 
stored  in  the  library  and  the  relationships  among  the  components  represented  in  the 
Library  model.  Each  answer  triggers  the  selection  of  appropriate  components  for  the 
customized  message  processing  subsystem  being  created  by  the  tool. 

•  System  composidcMi  follows  the  basic  process; 

Iiqjut: 

•  CARDS  library  model. 

•  User  knowledge  of  desired  system. 

Output: 

•  Appropriate  source  and/or  executable  code  extracted  from  the  reuse  library  for 
die  desired  system. 

Processing  Sequence: 

1.  User  clicks  on  Perform  Action  at  a  buildable  concept  node  (i.e.,  system/subsystem). 
Note  that  some  nodes  cannot  be  composed  into  a  system  because  they  cannot 
function  as  a  stand-alone  entity. 

2.  CLIPS  queries  AdaKNET  to  retrieve  roles  that  must  be  filled.  For  example,  a 
PRISM  message  generator  subsystem  has  roles  for  user  interface  and  message  fcx- 
mats.  CLIPS  determines  from  the  model  what  versions  of  components  are  available 
that  implement  the  user  interface  and  message  ftxmats. 

3.  CLIPS  asks  the  user  questions  that  allow  all  necessary  roles  to  be  filled. 

4.  CLIPS  asks  domain  dependent  questions  relevant  to  the  particular  system  being 
composed 

5.  If  the  preconditions  for  building  the  chosen  node  are  met  (i.e.,  aU  questions  are  an¬ 
swered),  CLIPS  then  harvests  the  system  by  collecting  all  the  role  filler  information. 


p 
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It  then  generates  calls  to  shell  scripts  which  put  the  sowce/execmtable  cocte  together 
in  UMT  q)ecified  directories. 

The  following  is  a  simple  example  of  system  ccmiposition  frtxn  an  actual  transcript  for  a  PRISM 
message  generatcM-  subsystem.  A  ‘help*  file  containing  detailed  information  about  the  operatioo 
of  the  U)ol  is  displayed  when  the  tool  is  initially  invoked. 

User  input  is  in  numeric  form  and  appears  after  the  arrow  symbol  Commentary  <m  the 
transcript  appears  in  italic  typeface. 

*  WELCOME  TO  THE  SYSTEM  COMPOSITION  DEMO  * 

♦  (Press  ENTER  to  continue)  * 

*******itt4t*****4t*****4t«******4i**««4i*«*«4>*4i4i*4>***4i*i^«*>»** 

Choose  the  number  corresponding  to 
your  choice  below,  then  press  ENTER: 

4i4t***4<iti**«**4>4t4>4>4i****4i***4i***4t4i***4>4t4i4t4i*«*«*«****4i4>«4i** 

1.  BuUd  the  current  component:  message_processing 
(traverse  the  command.center  LMDL  network) 

2.  Demo/execute  the  message_processing  code 

3.  Exit  (return  to  RLP) 


->1 

4i4t4t4i4i4i«*4i4t4i*4t*4i4>4>4>«4>**4t****4i*4>4<4i4i4i*4i4>4>***4i<l>4> 

*  Invoking  network  traversal  to  build  the  * 
message_processing  concept 
(Press  ENTER  to  continue) 

4>4i4i4>’^*<l>*4t*4>4>4>4>4>4E4>4>4>4>4t4>4>4t4>4i<l<*4>*4>4E4‘4>4>4>4>4>4t4i4<4>4i* 

4t4i4i>l>*<K**4i4>4>*4>4><l>4>4>4>4>4t**4t*>l>**4>4i**4>4>4>4>**4<4i*<t‘^** 

4i4t4i4>4t4t4(i^4t4>4i*4<4>4>4i4>4<4t4>4>4>4‘4i4>4»ti4i4i4>*4i>tt*4i4>4t4i4>4i4>4i4>4>*4<4i4<4i4i4i4>*4i4i 

Enter  the  directory  where  you  would  like  to  stOTe 
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the  message_processiiig  compooent,  then  press  ENTER. 
*************nt****if***  i^OTE  *****4'****4>********<‘**** 

*•*  the  directory  entered  must  be  a  vslid 
•♦♦directory  with  write  access. 

->Any-dir 

Which  of  the  following  do  you  want  to  include 
for  your  message_proce8sing  comptment 

mm0i^*if^itt*******m****^t*****************i***************** 

Source  code  only 
Executable(s)  only 

Both  source  code  AND  executabie(s) 

->1 

THE  CURRENT  CONCEPT  message .processing 
(has  role)  translates.validates 
(of  type)  message_translator_validatar 

Select  one  of  the  following  -  if  no  choice 

user  choice  is  desired,  choose  the  number  for  ‘None’, 

then  press  ENTER 

(type  ‘exit’  to  return  to  RLF) 

1.  KfTV 

2.  None 

->1 
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THE  CURRENT  CONCEPT  MTV 
Ou»  rde)  {vocesses 
(of  type)  gcc.message Jbnnat 

*4i4i*««*******4i*4i*4i***«***««**4i**4i*4i**#«**4i*«**4i**««***4> 

Select  (me  <x  ouxe  of  the  following, 
then  press  ENTER 

(type  ‘exit*  to  return  to  RLF) 

*4t***«**4t4i*4i***4i4i*4i**4t**4i«4>4t4i«i***4i*4i**4i«*******4i*****«« 

1.  e3a 

2.  intercept 

3.  nudet 

4.  roccsocc 

5.  iinsecure_tadil 

->2 

THE  CURRENT  CONCEPT  message_processing 
(has  role)  message.source 
(of  type)  message.generaUx' 

******************************************************* 

Select  one  ex  mose  of  the  following, 
then  press  ENTER 

(type  ‘exit’  to  return  to  RLF) 

******************************************************* 

1. 


->1 


ascii  prism  msg  ^n 
bb  prism  msg  gen 


m  Ak5-VC-tMJ13AAJL£AAI 


Note:  Inter«^<Hi  (mtitted  where  user  is  queried  fo- 

tbe  interface.type  of  ascii  prism  msg  gen,  the  XI 1  release 

to  use,  and  tlw  type  of  message  format  that  the  ascii  prism  msg  gen 

shouM  generate. 

m***********’¥***********************t‘****************** 

THE  CURRENT  CONCEPT  me8sage_processing 
(has  rdt)  component.cmnmunication 
(of  type)  interprocess.communicaticm 

******«***********«****4<**«4i4i*4<4i««**«4i4i*»4i*4>*********4t4t 

Select  one  of  the  following  -  if  no  choice  is  desired, 
choose  the  number  for  *None’, 
then  {xess  ENTER 

(^pe  ‘exit’  to  return  to  RLF) 

**4i4i4i«i*******4i***4i4i*4>**4i4i**4i4i4i*)|i***4>********4t****4>«*4t*4i 

1.  dec.message.q 

2.  plain_sys_man 

3.  sys_man_ingres 

4.  sys.man.sybase 

5.  None 

->2 

**4i*4>«i4>4i*i|i4i*4t4i*«4c*************4i«*<l>*4>4>4i*****4>***4t******4< 

END  OF  NETWORK  TRAVERSAL  ALGORITHM 
READY  TO  INVOKE  DOMAIN-DEPENDENT  QUESTIONS  - 
PRESS  ENTER  IX)  CONTINUE 

****4i*4t4i4i*«4i4>«***4i*4<  ABOUT  TO  HARVEST  **♦♦♦♦♦♦♦♦♦*♦♦♦** 
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I  - 

ASCn  PRISM  MESSAGE  GENERATOR 
PRESS  ENTER  TO  CONTINUE 

•  ll^l******************************^!***#***************** 

COMPONENT  RETRIEVAL  Dite:  Thu  Mar  25  09:06:37  EST  1993 
COMPONENT  SELECTION: 

Component  ascii  jMism  msg  gen  motif  - 

ASCn  PRISM  Message  Generator 


Message  Mix:  60,0,20^0 

Windowing  System:  Motif  Graphical  User  Interface 
Target  Direct(X7:  Anv-dir/asdi  orism  msg  gen  motif 
Packaging  Content:  Source  Code  Only 
Extracting  ascii  fwism  msg  («n  motifterc  .  .  .  Done. 

COMPONENT  RETRIEVAL  COMPLETED 
Press  RETURN  to  EXIT! 

4i«***4i4i4i**4>4i4i*4>****4i«*)|>*4i****«4i!*>**4i*4t*4«|i*’l>4>*4i****4t***** 

*«***«**4>*4i****«4i4^4i«**  about  to  HARVEST  ♦♦♦♦*•♦♦♦♦♦*♦** 

PLAIN  SYSTEM  MANAGER 
PRESS  ENTER  TO  CONTINUE 

COMPONENT  RETRIEVAL  Date:  Thu  Mar  25  09:07:11  EST  1993 
COMPONENT  SELECTION: 
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Component;  plain_s^_mao  - 

PRISM  System  Manager  without  MTV. 

Target  Directory;  /my-<lir/plain_sys_man 
Packaging  Ccmtent;  Source  Code  Only 
Extracting  plain_sys_man/src  .  .  .  Done. 

COMPONENT  RETRIEVAL  COMPLETED 
Press  <retum>  to  EXIT! 

**********************  /^OUT  TO  HARVEST  ♦♦♦♦***♦♦♦♦♦*** 


MTV 

PRESS  ENTER  TO  CONTINUE 

**************************************4141*41***41**111 4141  KtiH** 
******************************************************* 

COMPONENT  RETRIEVAL  Date;  Thu  Mar  25  09:07;32  EST  1993 
COMPONENT  SELECTION: 

Component  mtv  •  PRISM  Message  Translation  and 

1.  Validation  (MTV)  Standalone. 

Target  Directwy:  /my-dir/mtv 
Packaging  Content;  Source  Code  Only 
Extracting  mtv/src  .  .  .  Done. 

COMPONENT  RETRIEVAL  COMPLETED 
Press  <retum>  to  EXIT! 

Configuration  completed. 

Press  <returo>  to  continue. 

3.10  Component  Qualification  Tool 

The  exponent  Qualification  Tool  provides  our  users  a  method  of  qualifying  potential 
components  within  the  command  center  domain.  The  tool  also  provides  staff  software  engineers 
the  ability  to  qualify  potential  components  for  inclusion  in  the  CARDS  CCL  Model. 
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Each  component  class  has  relationships,  or  attributes,  that  a  comp<»ient  can  potentially  fill.  These 
relationships  describe  how  a  component  fits  within  a  particular  domain  such  as  the  command 
center  domain.  To  qualify  a  component,  a  component  is  evaluated  against  the  relationship  of 
the  component  class.  This  relationship  is  of  two  types:  critical  and  non-oitical.  The  critical 
relationshi{»  are  the  relationships  that  must  be  met  fcr  the  component  to  be  "qualified"  into 
the  component  class.  The  non-critical  relationships  are  ones  that  are  found  ficquendy  within 
the  domain  of  interest,  but  a  component  is  not  required  to  have.  Fw  example,  for  a  command 
center  domain  in  the  c(»nponent  classes  of  office  automation  software,  a  critical  relationship 
could  be  that  the  software  must  be  able  to  input  ascii  form  te«\,  but  a  non-critical  relationship 
could  be  that  the  component  could  have  a  spellchecker.  If  a  component  does  not  meet  all  critical 
roles  of  a  component  class,  it  cannot  be  considered  "qualified."  If  a  component  meets  all  oitical 
.  relationships,  but  not  all  of  the  non-critical  relationships,  it  is  "qualified"  for  that  particular 
component  class. 

By  quering  the  RLF  network,  the  component  qualification  tool  finds  the  criticial  and  non-critical 
roles  of  the  component  class.  It  then  prompts  the  user  with  questions  pertaining  to  the  relationship 
of  the  component  class  that  they  are  qualifying  against.  When  all  the  questions  are  answered, 
the  tool  then  generates  a  report  and  teUs  the  user  if  the  component  has  "passed"  or  "failed" 
qualification.  If  the  component  has  passed,  the  RLF  LMDL  code  is  generated  for  inclusion  into 
the  library  at  a  later  time. 

Components  which  provide  the  action,  "Qualify  Component",  are  included  in  Appendix  C, 
Library  Actions. 

3.11  System  Demonstrations 

The  CARDS  CCL  Model  provides  users  the  ability  to  evaluate  software  components  through 
demonstrations.  In  some  cases  the  demonstrations  will  be  fuU  working  versions  of  the  software 
with  no  limitations:  other  cases  will  be  demonstration  versions  of  the  software  supplied  by  the 
vendor  ot  a  "screen  capture"  walk-through  of  the  software. 

3.11.1  ascii  PRISM  msg  gen 

The  ascii  PRISM  msg  gen  component  generates  and  injects  simulated  ASCII  messages  into 
the  Generic  Command  Center  (GCC)  IPS.  It  is  configured  by  the  command  center  qterator 
through  the  user  interface  and  injects  messages  into  the  GCC  IPS  through  the  external  interfaces 
component. 

3.11.2  bb_PRISM_msg^en 

The  bb_PRISM_msg^en  component  generates  and  injects  simulated  bit-based  messages  into 
the  GCC  IPS.  It  is  configured  by  the  command  center  operator  through  the  uso*  interface  and 
injects  messages  into  the  GCC  IPS  through  the  external  interfaces  component 
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3.12  Interoperability 

In  CCL  release  3.2,  CARDS  implemented  trilateral  interq)erability,  i.e.,  intercq^eration  between 
CARDS,  ASSET,  and  DSRS.  CARDS  library  interoperability  uses  a  client/server  architecture 
to  retrieve  components  from  a  remote  library.  When  a  CARDS  user  requests  an  abstract, 
description,  ot  an  entire  component  residing  at  another  library,  a  program  is  run  which  conn«;ts 
to  a  central  CARDS  interoperability  server  running  on  the  CARDS  host  machine  in  Fairmont, 
WV.  This  server  then  verifies  the  credentials  of  the  user,  and  connects  to  the  remote  library  to 
retrieve  the  component  files.  The  files  are  retrieved  over  the  Internet  using  TCP/IP. 

The  user  does  not  need  to  do  anything  special  to  work  with  components  residing  at  another 
library.  Everything  is  handled  for  them. 

The  CARDS  library  includes  components  from  two  remote  libraries  -  DSRS  in  Falls  Church, 
VA,  and  ASSET  in  Morgantown,  WV. 

3.12.1  DSRS  Interoperability  Components 

The  following  four  interoperability  components  were  entered  into  the  CARDS  Command  Center 
domain  for  Release  3.2,  but  actually  exist  within  the  DSRS  Library.  These  components  are 
modeled  as  individuals  in  our  library,  but  the  actual  source  and  binary  files  reside  in  the  DSRS 
Library.  Actions  exist  at  the  individual  nodes  for  Display  Abstract  and  Extract  Contents. 

3.12.1.1  Screen_And_Data.Manager_Package 

Screen_And_Data_Manager_Package  is  an  Ada  package  that  provides  45  routines  for:  (1) 
managing  a  screen  definition;  (2)  displaying  data  to  a  user  at  a  terminal;  and  (3)  retrieving 
data  from  a  user  at  a  terminal.  AH  of  the  routines  in  the  package  operate  on  variables  of 
types  defined  in  the  package  specification.  A  screen  is  defined  to  be  an  array  of  records,  where 
each  record  defines  a  field  on  the  screen.  Screen_And_Data_Manager_Package  is  the  child  of 
ttyJnterface_software. 

Reuse  of  this  package  would  be  valuable  for  a  system  required  to  maintain,  modify,  and  query 
a  screen  definition,  as  well  as  to  display  and  retrieve  data  tq^om  a  user  at  a  terminal,  provided 
an  implementation  of  Terminal_lnterface_Package  is  available. 

3.12.1J2  Generic.Report.Handler 

Generic_Report_Handlw  package  was  designed  to  be  a  package  that  facilitates  the  generation 
of  printed  reptxts.  The  user  supplies  procedures  that  handle  the  generation  of  column  headers, 
footers,  etc.,  and  the  report  handler  calls  upon  user-supplied  procedures  as  necessary.  The 
primary  advantage  of  using  the  package  lies  in  the  "virtual  page"  abstraction  that  frees  the  user 
from  the  burden  of  ensuring  that  page  feeds  are  done  at  the  right  time.  Generic_Report_Handler 
is  the  child  of  tty  interface  software. 
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3.12.0  SafeJO 

SafeJtO  is  a  package  that  allows  the  user  to  input  data  types  from  the  keyboard  while  checking 
the  input  for  etrca^.  A  procedure  for  checking  input  of  characters  for  a  proper  sub*ran^  dl  the 
character  set  is  provided.  When  an  error  is  encountered,  an  errm  message  is  di^layed  and  the 
user  is  allowed  to  renter.  Ou^ut  routines  are  provided  to  allow  the  user  to  do  1/0  with  only 
<Hie  instantiatimi.  SafeJO  is  the  child  of  ttyJmerface_software. 

3.12.1.4  String_UtiliUes_Package 

String^Utilities.Package  is  an  Ada  package  that  provides  operations  for  parsing  and  maintaining 
strings  and  text.  The  subprograms  in  this  package  provide  the  user  with  the  c^ability  to  input 
an  entire  string  <x  just  a  segment  of  the  string  without  losing  the  index  position  within  the 
miginal  string.  The  lar^st  string  length  this  package  can  suppmt  is  system  dependent,  i.e., 
the  largest  positive  integer  supptxted  by  the  system.  String_Utilities_Package  is  the  child  of 
ttyjnterfacejsoftware. 

3.12.2  ASSET  Interoperability  Components 

The  following  three  interq)erability  components  were  entered  into  the  CARDS  Command  Center 
domain  for  Release  3.2,  but  actually  exist  within  the  ASSET  Library.  These  components  are 
modeled  as  individuals  in  our  library,  but  the  actual  source  and  binary  files  reside  in  the  ASSET 
Library.  Actions  exist  at  the  individual  nodes  for:  Display  Abstract,  Display  Relationships 
Graphically,  Display  Relationships  Textually,  and  Extract  Contents. 

3.12.2.1  AdaJSQL_bindings 

A  standard  binding  between  Ada  and  SQL  (Structured  (^ery  Language),  the  ANSI  and  DoD 
standard  for  accessing  commercial  relational  database  management  systems  (DBMSs).  SQL  was 
not  designed  to  be  embedded  within  ^>plicati<ms  in  general-purpose  progranuning  languages, 
such  as  Ada.  Previously  devel(q>ed  Ada-SQL  bindings  have  had  various  technical  drawbacks. 
Ada_SQL_bindings  is  the  child  of  language _binding5_software. 

A  prototype  Ada-SQL  binding  was  built  by  automating  the  SQL  Ada  Module  Extension 
methodology  (SAME).  SAME  is  a  method  for  building  Ada  ^)plicati(xis  that  access  DBMSs 
via  SQL.  SAME  extends  SQL  by  exploiting  the  features  of  Ada. 

3.12.2J  Optiiiiization_and_Planning_Tools 

This  pu:kage  provides  tools  for  mission  planning.  There  are  general  algorithms  lending 
themselves  to  generic  reusable  software  packa^,  including  the  SCI  terrain  masking  algtxithm, 
the  two-dimensional  implicit-sta^  multi-pass  dynantic  programming  algmithm,  the  two- 
dimensional  retrieval  algorithm,  the  three-dimensional  extensions  of  the  MDPA  and  route 
retrieval  algtnithm,  and  the  Dijkstra  shortest  path  algorithm.  Optimization_and_Planning_.Tools 
is  the  child  of  componerajilass. 


Page  52 


i  Alo-  V  c>ouid/uuw\M 


3.12.23  RMisable_Iini^_ProGes$in^acki^ 

The  Reusable  Ima^e  Processing  Package  is  a  set  of  reusable  Ada  packages  perfcvining 
various  image  processing  fimctions,  including  image  enhancing  and  image  statistic  modeling. 
Reusable_Image_Processing_Package  is  the  child  of  component _clas5. 

3.123  Interoperability  Metrics 

During  the  implementation  of  trilateral  interoperability,  staff  develq>ers  added  a  feature  to  the 
CARDS  Library  to  automate  the  collection  of  interoperation  metrics.  The  process  was  enlarged 
to  include  all  components  in  the  CARDS  library,  both  local  and  remote. 

Inter(q>erid>ility  metrics  collection  is  transparent  to  the  user.  The  metrics  collection  process  is 
invoked  by  the  CARDS  Library  actitms:  Extract  Contents,  Display  Abstract,  and  Provide 
Description.  The  following  information  is  logged  into  a  system  file: 

•  date 

■  time 

•  user  account  name 

•  library  origin  (e.g.,  CARDS,  DSRS,  ASSET) 

•  type  of  transaction  (extract,  display,  or  provide) 

•  success^ailure 

■  transaction  time 

•  component  acted  upon 

3.13  Future  Directions/Enhancements 
3.13.1  Structural  Changes 

The  main  thrust  of  future  development  of  the  C(X  Model  will  be  to  continue  adding  to  the 
knowledge  contained  in  the  model  to  supptxt  system  composition  and  other  tools. 

Currently  the  rq)re8entations  of  software  ardtitecture  details  in  the  model  are  not  fully  "fleshed 
out".  Futuie  plans  call  for  developing  improved  rq^resentations  for  software  architecture  within 
the  modeL  possibly  supported  by  other  tools.  These  improved  {presentations  will  then  be  used 
to  fill  out  the  software  ardiitecture  part  of  the  model. 
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Action  Changes 

The  Qualify  Component  action,  which  allows  the  user  to  see  ch*  obtain  a  printout  of  the  opdcmal 
and  required  features  of  the  current  category,  will  be  added  to  more  nodes  in  future  releases  of 
the  library. 

A  Feedback  action  allowing  the  library  user  to  send  feedback  to  the  CARDS  hotline  will  be 
added  to  the  Ubrary.  The  Obtain  Help  action  will  be  added  to  mcm  nodes. 

Each  of  the  remote  actions  will  be  merged  with  their  local  counterparts.  The  intention  is  that  the 
user  will  see  the  same  interface,  regardless  of  whether  the  component  is  stored  in  the  CARDS 
Library  or  another  library  with  whom  CARDS  inter(^)erates. 

3.133  Anticipated  Qualified  Componoits 

3.13.3.1  UNASJSALE  (Universal  Network  Architecture  Service/Software  Ardiitect’s  Life* 
cycle  Elnvironment) 

There  are  three  product  components  that  come  with  this  product: 

•  UNAS  development  kit:  a  suite  of  portable,  reusable  building  blocks  (a  library  of 
pre-existing  "primitive  parts"),  tools,  and  services.  UNAS  primitives  represent  a 
very  high  level  language  for  architecting  a  distributed  software  system. 

•  Software  Architect’s  Lifecycle  Environment  (SALE):  a  graphical  design  environ¬ 
ment  for  designing  systems  out  of  UNAS  parts.  The  environment  is 
knowledge-based,  where  UNAS  design  rules  and  performance  characteristics  consti¬ 
tute  the  knowledge  base.  The  environment  generates  source  code  for  an  architecture 
skeleton;  essentially,  it  provides  the  equivalent  of  a  UNAS  compiler  translating  the 
graphical  and  textual  UNAS  source  code  for  any  UNAS  supported  platform. 

•  UNAS  Runtime  Kit:  a  runtime  library  of  scalable  components  for  controlling,  in¬ 
strumenting,  monitoring,  debugging,  tuning  and  reconfiguring  a  network  of  UNAS 
objects. 

CARDS  will  attempt  a  two  step  approach  to  implementing  UNAS  and  SALE  into  the  CARDS 
Library: 

1.  Placing  it  into  an  existing  component  class  defined  within  the  GCCA.  Currently,  it  is 
placed  within  the  (unqualified)  CASE.tools  component  class;  however,  it  may  be 
later  qualified  under  another  class.  Possible  component  classes  include  inteiprocess 
communications,  system  status  and  control,  and/w  network  monitoring. 

2.  Using  UNAS  and  SALE  in  an  ongoing  CARDS  survey  of  software  architecture  con¬ 
cepts  and  technologies.  The  goal  of  this  longer-range  activity  is  to  capitalize  on  the 
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software  architecture/survey  to  provide  a  basis  for  qualifying  software 
architecture-oriented  CASE  technology  against  a  reference  model  of  software  archi¬ 
tecture  concq>ts;  this  would  be  analogous  to  the  way  CARDS  qualifies  command 
ctmtn'  comptments  against  a  GCCA. 

3.13.4  Anticipated  Sy^m  Demonstrations 

3.13.4.1  WingZ 

Win^  is  a  commercial  spreadsheet  package  and  has  very  mctensive  graphic  ctqjabilities  with 
3-D  imaging  available  as  well  as  a  Hyperscript  language  to  enhance  user  documents.  WingZ 
provi(tes  spreadsheet,  drawing,  hypermedia,  and  chart-making  capabilities. 

With  the  use  of  Datalink,  WingZ  can  interface  with  Sybase  and  send  2»QL  commands  to  the 
SQL  server  during  a  briefing  session.  Wingz  is  available  for  all  the  major  graphical  interfaces, 
making  it  v^  portable  and  usable. 

3.13.4J  UNASJ5ALE 

SALE  is  a  COTS  CASE  tool  assisting  the  software  architect  in  devdr^ing  distributed  iq>plicatic»is 
utilizing  the  UNAS  architectural  design  paradigm.  Through  SALE’S  graphical  user  interface, 
UNAS  objects  can  be  assembled  using  UNAS  rules  for  building  distributed  ^>plications.  UNAS 
is  a  process-based,  message-drivoi  language  framework  for  rapidly  developing  distributed 
^^Ucations.  The  final  product  of  a  SALE  session  is  UNAS-spedfic  Ada  code  for  the 
management  of  distributed  q)plications. 

UNAS_SALE,  developed  by  TRW  Systems  Engineering  and  Develr^ment  EHvision  in  Carson, 
CA,  provides  a  full  working  versirm  demonstration  of  the  product.  Due  to  licensing  agreements, 
the  only  means  to  access  the  full  working  version  SALE  demonstration  is  by  logging  into 
Solitaire,  the  CARDS  library  server,  by  users  with  a  CARDS  Unix  account.  UNAS_SALE  is 
not  currently  qualified  into  the  Command  Center  Domain,  although  it  is  anticipated  to  undergo 
the  CARDS  qualificatirm  process  in  the  future.  At  a  later  date,  there  will  be  a  "screen  capture” 
walk-througb  for  APS  users.  Currently  a  tuUnial  exists  for  the  UNAS.SALE  component 


PageSS 


APPENDIX  A  •  References 


[CARDS94a] 

CARDS  Library  User’s  Guide,  STARS-AC- 
B006/000/00,  Sept  93. 

[CARDS94b] 

CARDS  Version  Description  Document,  STARS>AC* 
OB007/001AX),  Sept  93. 

[CARDS94C] 

Library  Operation  Policies  and  Procedures,  Volume  IH  * 
Library  Develc^ment  Handbook,  Update  -  STARS-AC- 
04109A)02AX).  28  Feb  94. 

[CARDS94d] 

Technical  Concepts  Document,  STARS-AC- 

03536/003/00,  28  Feb  94. 

[CARDS93a] 

RLF  User’s  Manual,  Version  4.1,  STARS-UC- 
05156/013/00.  Mar  93. 

[CARDS93b] 

RLF  Modeler’s  Manual.  RLF  Version  4.1,  STARS-UC- 
05156/011/00,  Feb  93. 

tCARDS93cl 

RLF  Modeler  Tutorial,  STARS-UC-05 156/020/00,  Feb 
93. 

[CARDS92al 

Command  Center  Domain  Model  Description,  STARS- 
AC-04110/001/00,  Nov  92. 

[CARDS92b] 

RLF  Graphical  Browser  User’s  Guide,  STARS-SC- 
03065/D04A/00,  Jan  92. 

[DCA90] 

Command  Center  System  Architecture  and  TA/CE  Guid¬ 
ance,  Defense  Communications  Agency,  Sept  90. 

[DOD91] 

Multicommand  Required  Operational  Capability  for 
Command  Centers,  MROC  1-89,  DoD  and  Joint  Staff, 
Feb  91. 

[DISA91] 

Command  Center  Design  Handbook,  DISA,  91. 

[DOD92] 

DoD  Technical  Reference  Model,  Version  1.3,  Sept  92. 

[ESD92] 

Generic  Command  Center  Phase  2  Prototype  Summary 
Repmt,  ESD/AVS  Hanscom  AFB,  Jan  92. 

[GIAR92] 

CLIPS  User’s  Guide,  NASA  Joseph  Gianratano,  Sqpt  92. 

[KANG90] 

Feature-Oriented  Domain  Analysis  (FODA)  Feasibility 
Study,  SEI,  Kang,  Cohen,  Hess,  Novak,  Peterson,  Nov 
90. 

Page  A'l 


[NIST]  Applicatioas  Portability  Profile  (APP)  The  U  S.  Govern¬ 

ment’s  Open  System  Environment  Profile,  NIST  APP 
Special  Publication  500-187. 

[PRIE92]  Domain  Analysis  and  Software  Systems  Modeling,  IEEE 

Computer  Society  Press,  Prieto-Diaz,  Ruben  and  Arango, 
Guillermo,  92. 


Page  A-2 


APPENDIX  B  -  Glossary  of  Terms 


action 

advice 

aggregation 

application 

applicaticHi  platfmn 

architecture  modeling 

automated  message  handling 

category 

class 

command  center 


component 

component-based  library 


A  mechanism  permitting  a  user  of  the  RLF  gn4}hical 
browser  to  invoke  calls  to  the  underlying  qxa-ating 
system,  including  invoking  other  tools. 

An  opticm  offered  to  a  user  by  the  Reuse  Library 
Framework’s  graphical  browser  which  provides  expert 
guidance  by  invoking  appropriate  inferencers  to  aid  the 
user  in  navigating  a  model. 

Relationship  between  AdaKNET  concepts  which  express 
attributes,  characteristics,  feature  (as  the  term  is  used  in 
FODA  [KAN(j90],  functional  capabilities,  requirements 
Of  metrics:  that  is,  any  relationship  that  exists  between 
two  concepts  which  is  not  a  specializatitm  relationship. 

A  system  which  provides  a  set  of  general  services  for 
solving  some  type  of  user  problem. 

Hardware  and  software  that  provides  services  to  higher 
level  application  software  (e.g.  operating  system). 

The  process  of  creating  the  software  architecture(s)  that 
implement(s)  a  solution  to  the  problems  in  the  domain. 

Processing  of  strictly  formatted  messages. 

see  concq^t. 

see  concept. 

A  facility  from  which  a  commander  and  her/his  repre¬ 
sentatives  direct  operations  and  control  forces.  It  is  or¬ 
ganized  to  gather,  process,  analyze,  display  and  dissemi¬ 
nate  planning  and  operational  data  and  to  perform  other 
related  tasks. 

A  set  of  reusable  resources  that  are  related  by  virtue 
of  being  the  inputs  to  various  stages  of  the  software 
design  lifecycle,  including  requirements,  design,  code, 
test  cases,  documentation,  etc.  Components  are  the 
fundamental  elements  in  a  reusable  software  library. 

A  library  that  is  organized  around  a  collection  of  reusable 
com  ponents.  The  underlying  operational  concept  is 
that  of  search  and  retrieval  of  individual  components. 


concept 


converged 

display 

domain 

domain  analysis 


domain  criteria 


domain  engineering 


domain  model 


domain  modeling 
entity 


Gsmponents  f(Hmd  in  such  libraries  are  classified  in 
broad,  generalized  categories. 

An  atomic  unit  of  the  AdaKNET  knowledge  representa¬ 
tion  scheme,  representing  an  idea  or  thing,  also  known 
as  a  generic  concept,  a  category  or  a  class. 

Said  of  an  AdaKNET  role  range  for  which  the  minimum 
and  maximum  have  been  set  to  the  same  value. 

An  aid  to  briefing  such  as  video  monitor  (x  projection 
system. 

An  area  of  activity  or  knowledge  containing  applications 
which  share  a  set  of  common  capabilities  and  data. 

The  process  of  identifying,  collecting,  organizing,  analyz¬ 
ing  and  representing  the  relevant  information  in  a  domain, 
based  on  the  study  of  existing  systems  and  their  devel¬ 
opment  histories,  knowledge  cs^tured  from  domain  ex¬ 
perts.  underlying  thetxy  and  emerging  technology  withm 
the  domain. 

Specifications  that  a  potential  component  must  adhere 
to  in  order  to  obtain  acceptability  in  the  domain  and 
inclusion  in  the  library.  Domain  criteria  are  a  composite 
of  three  sets  of  constraints:  component  constraints, 
architectural  constraints,  and  implementation  constraints. 

An  encompassing  process  which  includes  domain  analy¬ 
sis  and  the  subsequent  construction  of  components,  meth¬ 
ods,  tools  and  suppmiing  documentation  that  address  the 
problems  of  system/subsystem  development  through  the 
application  of  the  knowledge  in  the  domain  model  and 
software  architecture. 

A  definition  of  the  functions,  objects,  data  and  relation¬ 
ships  in  a  domain,  consisting  of  a  concise  representation 
of  the  commtmalities  and  differences  of  the  problems  of 
the  domain  and  their  solutions  ({^plication  programs). 

The  process  of  encoding  knowledge  about  a  domain  into 
a  formalism 

A  particular  and  discrete  unit;  a  named  product,  process, 
object  or  relationship. 
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extomi  interfaces 

feature 

filler 

generic  architecture 

harvest 

individual 

individuation 

inferencer 

inherit 


The  physical  crninection  and  protocol  between  the  com¬ 
mand  center  and  other  information  systems. 

A  prominent  or  distinctive  usa-visible  aspect,  quality,  ot 
characteristic  of  a  software  system  or  systems. 

A  role  used  only  between  individuals.  The  filler  of  an 
individual’s  relationship  must  adhere  to  the  relationship’s 
restrictions.  Both  the  owner  and  the  "filler**  must  be  in 
dividuals. 

A  collection  of  high-level  paradigms  and  constraints  that 
characterize  the  commonality  and  variances  of  the  inter¬ 
actions  and  relationships  between  the  various  components 
in  a  sysmm. 

The  retrieval  of  the  source  and/tx  executable  code  for 
components  from  the  library  into  a  specified  directcxy 
during  system  composition. 

A  knowledge  representation  of  the  reusable  component  of 
the  librvy.  An  AdaKNET  term  for  Represents  a  specific 
instantiation  of  a  concept.  Also  known  as  an  individual 
concept,  an  object  or  an  instance. 

The  relationship  between  an  individual  to  its  subsuming 
concept  Indicates  that  an  individual  is  an  actual  instance 
of  the  idea  represented  by  the  concept. 

(Also  called  rule-base)  A  mechanism  which  uses  existing 
facts  and  rules  about  the  elements  of  a  model  to  perform 
reasoning  about  that  model  and  deduce  new  facts  and 
rules. 

see  inheritance. 


inheritance  A  mechanism  whereby  classes  make  use  of  the  proce¬ 

dures,  attributes,  and  /or  data  defined  in  other  classes. 

instance  see  individual. 

intermediate  levels  of  specialization  Concepts  that  partition  a  category  into  subcategcxies. 

knowledge-based  software  Software  engineering  with  tools  that  utilize  a  knowledge 

engineering  representation  of  a  dtnnain  taui/or  process. 

library  model  A  model  that  represents  the  domain  components  and  the 

relationships  between  them. 
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1 

1 

library  modeling 

The  process  of  building  a  library  model  that  accurately 
reflects  the  functionality  and  structure  of  the  target 
domain. 

1 

meta-model 

"model  of  modeling"  or  the  knowledge-representation 
formalism  used  to  encode  library  models. 

1 

1 

1 

model-based  library 

A  library  that  is  organized  around  the  principle  that 
what  matters  in  a  repository  is  the  context  in  which 
reusable  software  components  are  used  and  the  relation¬ 
ships  among  components.  The  focus  of  a  model-based 

Ubrary  is  the  model  (requirements,  architectures,  design 
decisions  and  rationales)  and  the  soft  ware  which  imple¬ 
ments  these  models. 

1 

1 

multilevel  security 

Information  processing  and  communications  which  allow 
two  more  classiflcation  levels  of  infcHmation  to  be 
processed  simultaneously  within  the  same  system  when 
some  users  are  not  cleared  for  all  levels  of  infcxmation 
present. 

1 

object 

see  individual. 

■ 

1 

(role)  name 

Refers  to  the  name  of  an  AdaKNET  aggregation  relation¬ 
ship. 

1 

■ 

operator 

A  user  who  employs  the  resources  of  command  center 
software  to  meet  mission  objectives. 

1 

■ 

(role)  range 

The  number  of  simultaneous  cqpies  that  may  exist  of  an 

AdaKNET  aggregation  relationship. 

1 

1 

reusable  component 

A  component  (including  requirements,  designs,  code, 
test  data,  specifications,  documentation,  expertise  etc.) 
designed  and  implemented  for  the  specific  purpt^e  of 
being  reused. 

1 

role 

An  AdaKNET  term  which  refers  to  an  aggregation 
("consists  of’)  relationship  between  two  concepts. 

1 

1 

role  restriction 

Refna  to  an  inherited  AdaKNET  aggregation  relationship 
which  is  narrowed  at  the  inheriting  concept,  eitho-  by 
further  restricting  the  range  or  by  further  restricting  the 
type. 

1 

1 

rule-base 

(Also  called  inf^encer)  A  collection  of  rules  about  the 
elements  of  a  domain.  A  rule  describes  the  relationships, 
requirements  and  constraints  among  components. 

E 
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software  architecture 

software  reuse 
specialization 
standard  descriptors 

subsume 

system  composition 
taxonomy 
(role)  type 
workstation 


High-level  paradigms  and  constraints  characterizing  the 
stnicture  of  operations  and  objects,  their  interfaces  and 
control  to  supptxt  the  implementation  of  applications  in 
a  domain.  Includes  a  descriptitm  of  each  software  com¬ 
ponent’s  ^ctionality,  name,  parameters  and  their  types, 
and  a  descriptitm  of  the  components’  interrelationships. 

The  process  of  implementing  new  software  systems  using 
existing  software  infcHtnation. 

The  act  of  declaring  that  one  concept  represents  a 
narrowing  of  the  idea  represented  by  another  concept. 

Basic  conceptual  units  that  form  the  interface  between 
domain  ar  chitectures  and  reusable  components  (i.e., 
high-  level  mini-specs  for  a  class  of  components). 

Having  an  is-a  relation  with  a  concept  where  Ute  subsum¬ 
ing  concept  is  a  larger  and  more  abstract  categcny  (e.g., 
X  is_a  Z  and  Y  is_a  Z  therefore  Z  subsumes  X  and  Y). 

The  automatic  configuration  of  a  prototype  system  based 
on  hardware  and  software  requirements. 

The  thecxy,  principles  and  process  of  categorizing  entities 
in  established  categories. 

The  allowable  range  of  values  of  an  AdaKNET  aggrega¬ 
tion  role. 

An  electronic  hardware  component  of  the  command 
center  through  which  the  user  can  communicate,  process 
information  and  prepare  briefings. 
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APPENDIX  C  -  LIBRARY  ACTIONS 

Actions  can  be  any  executable  command  or  saipt.  If  an  "action"  is  included  at  a  concept,  the 
phrase  Perform  Action  appears  on  the  pop-up  menu  when  the  user  chooses  the  node  which 
represents  that  concept.  Another  pop-up  menu  appears  when  Perform  Action  is  chosen.  Tbus 
menu  displays  the  action  or  actions  available  at  that  concept.  If  there  are  no  actions  at  the 
concept,  the  Perform  Action  option  is  not  presented  as  a  menu  choice. 

Many  actions  have  been  added  to  the  model  since  the  last  version  of  this  document  It  is  the 
intention  that  some  actions,  currently  invoked  at  a  limited  number  of  concept,  will  eventually 
be  available  at  many  others  and  that  additional  actions  will  be  implemented. 

The  list  of  invocable  actions  and  a  shtxt  description  follows: 

•  Display  Abstract  -  Display  an  Abstract  outlining  the  features  and  ciqjabilities  of  an 
asset. 

•  Display  Relationships  Graphically-This  fimction  displays  relationships  of  the 
library  model  in  a  graphical  format. 

•  Display  Relationships  Textually-This  function  displays  relationships  of  the  library 
model  in  a  textual  format. 

•  Extract  Contents  -  This  functon  provides  the  ability  to  extract  the  contents  of 
directories  and/or  files  from  an  RLP  Library  to  a  user  specified  target  directory. 

•  Obtain  Help  -This  fimcton  provides  the  ability  to  view  an  ascii  formatted  file 
containing  pertinent  help  information  for  a  particular  node. 

•  Produce  System  -  This  function  calls  the  System  Composition  Tool. 

•  Provide  Description  -  Displays  the  Description  file  for  a  particular  node.  The  pre¬ 
view  utility  is  used  to  display  the  Description  file.  It  is  available  at  all  local 
concepts  in  the  model. 

•  Run  Demo  -This  function  allows  the  user  to  execute  a  demonstration  in  a  subshell. 
Demonstrations  called  through  this  action  generally  have  a  graphical  user  interface. 

•  Show  Assessment  -  Tfiis  function  provides  the  user  with  the  ability  to  view  a 
Product  Evaluation  Report. 

•  View.  message.format  -  This  function  displays  information  about  message  formats. 

•  View  Roadmap  -  This  function  allows  the  us^-  to  view  text  describing  major 
sections  of  the  model. 
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•  Qualify  Component-  -This  funcdon  {n’ovides  the  ability  to  view  or  obtain  a  printout 
of  the  rational  and  requir»l  features  of  the  current  category. 

•  Picture  Image-  This  function  provides  the  ability  to  view  graphic  images  related  to 
the  current  node. 
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